![](https://secure.gravatar.com/avatar/2a726b0de1ade0be11fb5bc5a383d71d.jpg?s=120&d=mm&r=g)
On Fri, May 16, 2008 10:08 am, David Cournapeau wrote:
Pearu Peterson wrote:
I agree on the independence. On the other hand, the signatures of wrapper functions should be identical for all backends
Yes, that's my main concern, specially if the code is put in scikits and get a life on its own, we should make sure the C code call convention is the same (the other solution would be for each backend to provide a fatter wrapper, with fft implementation at the python level, but then there is python code duplication).
(the other solution should be avoided if possible)
The content of signature files that can be different for different backends, is the callprotoargument and callstatement sections in .pyf files.
Ok, bear with me here for being slow, but I don't know anything about f2py :) Do the callprotoargument and callstatement apply to all functions from the included functions ?
No, the suggestion was to split the pyf file into 3 pieces: part 0, the call* calles, part 1. Now that I look at it, it seems that also call* parts are identical for all backends except the module name part. This should make also the split of files unnecessary. I'll take a look at the branch and see if I can figure something easier out..
Note that the wrapper function names do not need to contain the name of a backend.
At the C level, the function should certainly have different names,
Why? Isn't C functions static and so there should be no conflicts provided that all backends have their own extension modules. May be I am overlooking something..
and I didn't find how to wrap a C function foo_bar as a foo function in the f2py generated module. I didn't look for long, though.
That's easy, one should use `fortranname` statement in pyd files. Search fortranname in f2py users manual. Pearu