[SciPy-dev] fftpack: building all backends and setting them at runtime (was dropping djbfft)

[Pearu Peterson]

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