Jari Pennanen <jari.penna...@gmail.com> added the comment:
> Note that I don't think that just providing an alternative order of
build_py and build_ext would solve the SWIG issue - e.g. build_py
wouldn't know about the new files SWIG generates unless the SWIG build
process explicitly tells the build_py command about these new files.
I don't think this is the case, let me explain:
Usually to my naive understanding, (I've just developed first SWIG
python extension) the generated .py filenames are *known by name*
beforehand, thus I can do following:
#!/usr/bin/env python
from distutils.core import setup, Extension
from distutils.command.build_py import build_py
dist = setup(name='mypythonmodule',
ext_modules=[
Extension('swiggedmodule', ['swiggedinterface.i'],
...
)
],
py_modules=['swiggedmodule'], # We *know* that the SWIG
# generation creates this module.
)
# Rerun the build_py to ensure that swig generated py is build
build_py = build_py(dist)
build_py.ensure_finalized()
build_py.run()
The very first line of `swiggedinterface.i` is the key here, it is
created by us, which explicitely says it will create swiggedmodule.py:
%module "swiggedmodule"
...
This fact makes us sure that it creates only swiggedmodule.py and we can
safely put it in setup py without any guessing work. This is why the
simply re-running the built_py works, or running "setup.py build_ext
build_py" but users of the module shouldn't need to use different way of
building the swig modules than other modules.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue7562>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
