[SciPy-Dev] On pulling fwrap refactor into upstream SciPy

[Dag Sverre Seljebotn]

On 02/08/2011 12:09 PM, Pauli Virtanen wrote:
> Tue, 08 Feb 2011 10:56:46 +0100, Dag Sverre Seljebotn wrote:
> [clip]
>    
>> I don't have push rights or a track record with the project so I can't
>> really make anything happen on my own accord. I'll meet Pauli in a
>> Cython workshop the first week of April, so hopefully we can talk about
>> it then if nothing happens before.
>>      
> Sorry, I didn't yet find the time to look deeply into this.
> Anyway, two quick questions (I'm not yet familiar with Fwrap):
>
> 1) Have the *.pyx files generated by Fwrap been manually modified?
>     Or can Fwrap re-generate them directly from the *.f sources?
>    

It surely can't do from .f sources (the .pyf files contains *tons* of 
additional specifications).

It does get it 80% there from the .pyf files, and then manual 
modification is needed.

>     If manual changes are necessary, can they be cleanly separated
>     from the automatic boilerplate?
>    

Not code-wise, but history-wise.

That is, I have several times changed the code generation of Fwrap, 
regenerated the boilerplate, and put the manual changes back in (using git).

The way I've done it is that in each .pyx file there's two hashes

# Fwrap: self-sha1 0345345bbadc0324...
# Fwrap: pyf-sha1 dc03240345345bba...

(First one is related to .f parsing, second one to a second stage where 
.pyf changes are added.)

Then, git-blame can be used to get the right commit, create a branch 
from it, regenerate the wrapper, and then you can merge back cleanly. 
The fwrap command line utility will do some hand-holding with git for 
you for this purpose, so you don't need to dig for those hashes yourself.


> 2) Is Fwrap a Cythoning-time dependency?
>    

No.

Dag Sverre