SWIG: two modules, but only one can be installed

Hallöchen! I have a module here that makes a library available to python using SWIG. The setup.py file looks like this: setup(name = 'my', py_modules = ['mymodule','my'], ext_modules = [Extension('_mymodule', sources = ['mymodule.c', 'mymodule.i'])] ) Unfortunately, SWIG creates not only "_mymodule" but also "mymodule". However, the above script must be called twice, because at the first run, "mymodule" doesn't exist yet. (This is accompanied by error messages, by the way.) A solution without the necessaty of calling twice and without errors is setup(name = 'my', py_modules = ['my'], ext_modules = [Extension('_mymodule', sources = ['mymodule.c', 'mymodule.i'])] ) setup(name = 'mymodule', py_modules = ['mymodule'], ) I.e., calling "setup" twice in the same setup.py. But is this really the clean solution for this problem? Thank you! Tschö, Torsten Bronger. -- Torsten Bronger, aquisgrana, europa vetus

Hallöchen!
(I personally prefer "Dear Sirs") <snippage>
But mymodule.py doesn't exist as a source file. Instead, it is *created* by SWIG.
Ah. It sounds like it's just the SWIG naming conventions that irritate you. For mymodule.i, SWIG will generate _mymodule.{so|dll} and mymodule.py (containing the shadow wrapper code). distutils is aware of that naming convention. Try just: setup(name = 'my', ext_modules = [Extension('mymodule', sources = ['mymodule.i'])] and distutils should do the Right Thing (tm). - Lars

Hallöchen! Lars Immisch <lars@ibp.de> writes:
I don't think so. ;-)
Well, I had also tried this variant, but then distutils generates a mymodule.lib instead of _mymodule.lib and the Microsoft linker complains about not finding the external symbol "initmymodule".
and distutils should do the Right Thing (tm).
Due to my compiler situation, I feel forced to use Python 2.3. Could this be the reason for my problem? Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus

Hallöchen!
(I personally prefer "Dear Sirs") <snippage>
But mymodule.py doesn't exist as a source file. Instead, it is *created* by SWIG.
Ah. It sounds like it's just the SWIG naming conventions that irritate you. For mymodule.i, SWIG will generate _mymodule.{so|dll} and mymodule.py (containing the shadow wrapper code). distutils is aware of that naming convention. Try just: setup(name = 'my', ext_modules = [Extension('mymodule', sources = ['mymodule.i'])] and distutils should do the Right Thing (tm). - Lars

Hallöchen! Lars Immisch <lars@ibp.de> writes:
I don't think so. ;-)
Well, I had also tried this variant, but then distutils generates a mymodule.lib instead of _mymodule.lib and the Microsoft linker complains about not finding the external symbol "initmymodule".
and distutils should do the Right Thing (tm).
Due to my compiler situation, I feel forced to use Python 2.3. Could this be the reason for my problem? Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus
participants (2)
-
Lars Immisch
-
Torsten Bronger