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. --keith
On Mon, Dec 30, 2002 at 12:56:20PM -0800, Keith Jackson wrote:
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.
Go for it! 2.3alpha1 is due tomorrow so you won't be able to be finished in time, but there will almost certainly be a 2.3alpha2. --amk (www.amk.ca) ROMEO: He jests at scars that never felt a wound. -- _Romeo and Juliet_, II, ii
Keith Jackson <krjackson@lbl.gov> 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. Paul. -- This signature intentionally left blank
Paul Moore wrote:
Keith Jackson <krjackson@lbl.gov> 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/
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. --keith ---------------------------------------------------------------- Keith R. Jackson KRJackson@lbl.gov Grid Technology Group (510) 486-4401 Lawrence Berkeley National Laboratory http://www-itg.lbl.gov/~kjackson/
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/
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? 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. --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:
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?
Sounds like a plan. -- 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/
"M.-A. Lemburg" <mal@lemburg.com> writes:
Keith Jackson wrote:
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.
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 Compiled with g++
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().
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. Greetings Berthold -- bhoel@web.de / http://starship.python.net/crew/bhoel/ It is unlawful to use this email address for unsolicited ads (USC Title 47 Sec.227). I will assess a US$500 charge for reviewing and deleting each unsolicited ad.
Berthold Höllmann wrote:
"M.-A. Lemburg" <mal@lemburg.com> 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/
On Friday, Jan 3, 2003, at 23:31 Europe/Amsterdam, Keith Jackson wrote:
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.
You won't get this to work on MacOS9. The best solution is probably to tell the user what the unix command line would have been (preferably in a dialog, but a print is probably okay too) and exit. -- Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman
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/
participants (6)
-
A.M. Kuchling -
Berthold Höllmann -
Jack Jansen -
Keith Jackson -
M.-A. Lemburg -
Paul Moore