[Distutils] build subcommand order
Lars Immisch
lars at ibp.de
Fri Mar 26 09:19:20 EST 2004
M.-A. Lemburg wrote:
> Dan Schult wrote:
>
>> Thanks for the help---
>> I put in the cmdclass only {build: my_build}
>> since I don't have a my_build_py.
>> It works great!
>>
>> Still it seems that everyone using Swig to
>> create packages will either have to run setup twice, or put this code
>> in.
>
>
> Hmm, doesn't the existing SWIG support already add the Python
> module ?
I don't think so. In the first place, swig should create .py files only
if -shadow is passed, and I see no obvious support for this argument in
the distutils code.
I *might* be missing something obvious - at least Dan's setup must have
created a .py file.
> I know that SWIG support is very limited in distutils, but
> I would be surprised if it is that limited :-)
>
> (I'll have to deal with distutils + SWIG in the near future too.)
I think it is that limited.
Swig is run without include path arguments (-Ifoo), macro definitions or
undefs and only one possible extra argument (-cpp).
Basically, swig is run as a side effect to build_ext.
As Dan discovered, this is a problem in itself, since swig may generate
Python code.
I proposed a patch a week ago that addresses the missing arguments
problem, but reuses the include_dirs, define_macros and undef_macros
from the compilation stage.
I am playing with a patch that makes build_ext a three-step process:
- swig
- compile
- link
with the additional options swig_include_dirs, swig_define_macros,
swig_undef_macros and extra_swig_args.
This doesn't solve Dan's problem, though.
Maybe even this does not go far enough and swig could become an early
step in the entire chain:
build_swig
build_py
build_clibs
build_ext
build_scripts
I believe this would require handling Swig extensions with a new
Extension subclass, otherwise I couldn't see how depencies would be handled.
But I haven't read enough distutils code yet.
I'd be happy to hear other ideas.
- Lars
More information about the Distutils-SIG
mailing list