[issue7562] Custom order for the subcommands of build

[Jari Pennanen]

New submission from Jari Pennanen :

Long story short: Sometimes build_ext should be run before build_py, or 
something similar.

As an example when using SWIG and setup.py the build order is incorrect: 
During build_ext the SWIG generates .py files that should be used during 
build_py, but since build_py was already ran this doesn't work.

It would be useful if one could for example define custom order for 
subcommands in setup, in this case like: 

setup(..., build_order=['build_ext', 'build_py'])

If adding a new keyword argument to setup is not an option, some other 
way to specify custom build order should be considered.

This is common problem especially using SWIG. Discussion about this 
issue was in here http://mail.python.org/pipermail/distutils-sig/2009-
December/015010.html the workaround for SWIG case is to use following 
setup.py:

   #!/usr/bin/env python
   from distutils.core import setup, Extension
   from distutils.command.build_py import build_py

   dist = setup(...)

   # Rerun the build_py
   build_py = build_py(dist)
   build_py.ensure_finalized()
   build_py.run()

--
assignee: tarek
components: Distutils
messages: 96798
nosy: ciantic, tarek
severity: normal
status: open
title: Custom order for the subcommands of build
type: feature request

___
Python tracker 
<http://bugs.python.org/issue7562>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7562] Custom order for the subcommands of build

[Jari Pennanen]

Jari Pennanen  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 
<http://bugs.python.org/issue7562>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com