[Distutils] build subcommand order

[Lars Immisch]

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