To my delight there is support for swig built into
distutils.  However a few problems exist with the support.

- there is no way to specify any extra flags to the
swig command (I need -I/usr/include -DHAVE_LONG_LONG);
- swig generates two files, the XXX_wrap.c file which
is turned into a _XXX.so file, and a XXX.py file. 
distutils only deals with the XXX_wrap.c file.

I have no suggested fix for these problems, but
problems they are.

(Python from CVS HEAD on Fedora Core 2).

Logged In: YES 
user_id=43607

Part of the problem described here (the extra options that
need to be given to swig) is solved by [ 1046644 ] improving
distutils swig support (2).  However, the other part is
still a problem.

Logged In: YES 
user_id=43607

I just came up with a possible solution:

In command/build.py change the order of the
build.sub_commands list and put the entry for build_ext
before build_py.

The question is, does this cause a problem for anybody?

Logged In: YES 
user_id=11105

Haven't read the original problem (I don't use swig myself),
but if changing the order of the sub_commands list than it
can as well be done in the setup script by installing a
custom build command.

Logged In: YES 
user_id=43607

Hmm, you can't really call that "decent swig support" then,
can you?
If this "solution" were properly documented (in a place one
would notice when trying to create a setup.py to do swig!)
then it wouldn't be too much of a problem, but I wouldn't
know where that would be.

So, if my change doesn't cause any detrimental effects I'd
much rather see it fixed that way.

Logged In: YES 
user_id=11105

> Hmm, you can't really call that "decent swig support"
then, can you?

Of course not ;-)

And I have setup scripts myself which would be more happy
with this change, anyway, because they need the extensions
built with build_ext to generate python modules.

So, personally, I'm +1 on this change (but what does this
count).

Same with issue2624?