[issue7562] Custom order for the subcommands of build

[Jari Pennanen]

Jari Pennanen <jari.pennanen at 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 <report at bugs.python.org>
<http://bugs.python.org/issue7562>
_______________________________________