Paul Moore wrote:

Keith Jackson writes:

...

What are folks feelings about supporting recent versions of swig in distutils? I'd be willing to do the changes to get this working again, but only if people are interested. Right now I just use my own run_swig method, but I'd rather have this work as a core part of distutils.

I think this is probably a good idea. SWIG 1.1 is pretty much unmaintained these days, and 1.3 is the de facto current version (even if it's theoretically not yet designated as stable).

But my interest is purely theoretical. I don't have any code which uses SWIG at the moment, and there may well be people out there currently using the Distutils/SWIG 1.1 support, and who can't make the necessary changes to go to SWIG 1.3 (the two versions aren't compatible).

If you want to support a gradual migration, maybe it would pe possible to have SWIG support which recognises a swig_version argument somewhere, which could be set to 1.1 or 1.3.

What changes would have to be implemented in distutils for swig 1.3 ? If it's just the names of a few options I'd suggest to make the swig support smart enough to support both versions as Keith suggests. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/

I think I'd like to include an "extra_swig_args=" option that would allow users to pass in a string that would be passed directly to the swig command line before the "-o" option. Thoughts? --keith ---------------------------------------------------------------- Keith R. Jackson KRJackson@lbl.gov Grid Technology Group (510) 486-4401 Lawrence Berkeley National Laboratory http://www-itg.lbl.gov/~kjackson/

Keith Jackson wrote:

I've run into a bit of a problem in getting swig 1.3.x working with distutils. Running swig on an interface file now produces two files by default; a python shadow class file and the C/C++ wrap file.

For example: swig -python example.i produces example_wrap.c and example.py. It then expects that the generated .so will be _example.so.

The problem is with the generated python file. How would we get it added into the python modules. It looks like build_py runs before build_ext, and even if they didn't there isn't a communication mechanism to have one Command sub-class add information into another Command sub-class. Any thoughts about how this might be addressed?

There is: you have to reinitialize the command and then refinalize it, e.g. # Reinitialize build_ext command with extra defines build_ext = self.distribution.reinitialize_command('build_ext') build_ext.ensure_finalized() However, this doesn't rerun the command. That should be doable with self.distribution.run_command('build_py') though.

If this can be solved, everything else seems to be working fine. Everything works fine for generating my modules since I don't use the automated shadow class generation of swig. Getting this working for both 1.1.x and 1.3.x required minimal changes to the build_ext class.

-- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/

Keith Jackson wrote:

M.-A. Lemburg wrote:

...

What changes would have to be implemented in distutils for swig 1.3 ? If it's just the names of a few options I'd suggest to make the swig support smart enough to support both versions as Keith suggests.

I think the only changes are in the options. Everything else should stay the same. I'm currently planning on making 1.3 the default version, and requiring an explicit swig_version option to revert to 1.1.

Isn't there a way to tell the SWIG version by calling swig itself ? I think distutils should figure this one out by itself. Alas, the program you're compiling probably is bound to a specific SWIG version anyway, so maybe we need a helper which people can call in their setup.py files to check, e.g. swig_version(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/

Berthold Höllmann wrote:

"M.-A. Lemburg" writes:

...

Keith Jackson wrote:

...

M.-A. Lemburg wrote: There is of course a way to get the swig version:

~/ [1]>/usr/bin/swig -version

SWIG Version 1.3.13u-20020910-1829 Copyright (c) 1995-1998 University of Utah and the Regents of the University of California Copyright (c) 1998-2001 University of Chicago

Compiled with CC ~/ [1]>/usr/local/bin/swig -version

SWIG Version 1.1 (Build 786) Copyright (c) 1995-98 University of Utah and the Regents of the University of California

What is the right non-platform specific way to execute a command, and get the output back? The distutils spawn command doesn't return the output, and popen doesn't exist on Macs. I don't normally work with Macs, so any suggestions would be appreciated.

Maybe there should also be a way to select a special swig executable like "--swig=swig1.1" to be able to have several swig exectables at the same time, and switch to another version if needed. The alternative would be to have several "swig"s and to fiddle with the PATH, but an option would probably be easier for some OSs.

That sounds like a good idea. --keith ---------------------------------------------------------------- Keith R. Jackson KRJackson@lbl.gov Grid Technology Group (510) 486-4401 Lawrence Berkeley National Laboratory http://www-itg.lbl.gov/~kjackson/

M.-A. Lemburg wrote:

Isn't there a way to tell the SWIG version by calling swig itself ? I think distutils should figure this one out by itself.

Sounds good.

Alas, the program you're compiling probably is bound to a specific SWIG version anyway, so maybe we need a helper which people can call in their setup.py files to check, e.g. swig_version().

Ok, that sounds pretty useful. --keith ---------------------------------------------------------------- Keith R. Jackson KRJackson@lbl.gov Grid Technology Group (510) 486-4401 Lawrence Berkeley National Laboratory http://www-itg.lbl.gov/~kjackson/