[SciPy-dev] Is it ok to depend on ctypes for scipy code ?

[David Cournapeau]

Travis Oliphant wrote:
>> We are still maintaining 2.3 compatibility.
>>
>>  
>>
>
> Yes, but I don't think we would mind having some code that requires 
> another library to be installed to be used (as long as it builds and 
> installs without it).   For example, some code in SciPy requires the PIL 
> in order to be useful. 
>
> So, is it just a matter of inserting the dummy function
>
> initfoo()
>
I finally got it :) Your remark made me understand the thing that Robert 
was talking about. As I still couldn't understand the whole issue yet, I 
installed the whole visual studio thing and tried a fake module to get 
the problem. This all boils down to the fact that whereas on linux (and 
mac os X at least), a python module and a shared library really are the 
same thing, on windows, they are quite a different beast. For the 
record, here are the different problems as far as I understand:
    - first, distutils, at least on windows, is looking for a function 
initmodule (this is what you and Robert were talking about), and is 
needed for the link to success. The reason why I didn't understand 
Robert's explanation at all is that distutils *explicitely* tells VS to 
export the initmodule function, hence has to exist.
    - then, the obvious quick fix being as Travis suggested to put a 
fake function, but this does not seem to help much (eg the library 
builds but is not usable from ctypes).

I knew there were some differences between "Linux" and windows linking 
models (symbol visibility), but they are actually much deeper than I 
thought.

I will try to see if I can easily extend numpy.distutils to build "real" 
shared libraries (using oof as a reference, as mentionned by Rober on a 
different ML I found by googling for the problem), which should solve 
the whole issue, right ? Or am I missing something else ?

David