From Rafal Dowgird Tue Dec 3 05:14:04 2002 From: Rafal Dowgird (Rafal Dowgird) Date: Tue Dec 3 05:14:04 2002 Subject: [Distutils] Bug/patch question, WinNT, Borland C linker, spaces in paths Message-ID: <184319639577.20021203110944@bms.com.pl> Hello, There is a bug in distutils that breaks Borland C linker. Distutils tries to pass search paths to the linker as "/LD:/Program Files/samplepath" This causes the linker to bail out with an error message suggesting that the path argument is mistreated as an object file. It seems that the linker expects a different quoting scheme that the one used by distutils. I have done some experimenting and it turns out that: /L"D:/Program Files/samplepath" /LD:/Program" "Files/samplepath are both OK. Unfortunately: /L "D:/Program Files/samplepath" does not work - there should be no whitespace between '/L' and the path, so passing '/L' and the path as separate arguments does not work. The piece of code responsible for the quoting is _nt_quote_args function in spawn.py. The following patch 'fixes' the quoting scheme. This is the output from 'cvs diff spawn.py': Index: spawn.py =================================================================== RCS file: /cvsroot/python/distutils/distutils/spawn.py,v retrieving revision 1.16 diff -r1.16 spawn.py 62,63c62 < if string.find(args[i], ' ') != -1: < args[i] = '"%s"' % args[i] --- > args[i] = args[i].replace(' ','" "') Instead of putting the whole space-containing argument into quotes, it only quotes spaces. Unfortunately there is no reason for this not to break other compilers. Due to infelicities in WinApi (child process gets the whole command line, not split into arguments) it's up to the compiler/linker to parse the command line and as far as I know there is no standard way of encoding arguments that contain spaces. Now, the questions: 1. Can anyone test the above patch with other compilers? I only have Borland. 2. I think that one 'standard' argument quoting function might not be sufficient. Perhaps _nt_quote_args should be moved into CCompiler class hierarchy? This way every compiler could override the standard quoting function without the risk of breaking other compilers. 3. I have just started looking at the distutils source code and I am not a Python guru, so perhaps there is another simple way to fix this bug? Regards, Rafal Dowgird From mal@lemburg.com Tue Dec 3 05:46:13 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue Dec 3 05:46:13 2002 Subject: [Distutils] Bug/patch question, WinNT, Borland C linker, spaces in paths References: <184319639577.20021203110944@bms.com.pl> Message-ID: <3DEC8B2D.8020406@lemburg.com> Rafal Dowgird wrote: > Hello, > > There is a bug in distutils that breaks Borland C linker. Distutils > tries to pass search paths to the linker as > "/LD:/Program Files/samplepath" Are you sure that it's worth adding quoting support for paths with embedded spaces to distutils is worth the effort ? I know that spaces in paths of executables and DLLs cause endless problems on Windows and most of these can easily be avoided by installing program files to a non-space-containing path location on the disk. > This causes the linker to bail out with an error message suggesting > that the path argument is mistreated as an object file. It seems that > the linker expects a different quoting scheme that the one used by > distutils. I have done some experimenting and it turns out that: > > /L"D:/Program Files/samplepath" > /LD:/Program" "Files/samplepath > > are both OK. Unfortunately: > > /L "D:/Program Files/samplepath" > > does not work - there should be no whitespace between '/L' and the > path, so passing '/L' and the path as separate arguments does not > work. I think that the first variant is what is accepted as standard on most OSes, however, the second variant seems to be accepted by the Windows command shell as well, so maybe you're right in that this is the way to go. The space between the option and the argument looks like an application level quirk to me. > The piece of code responsible for the quoting is _nt_quote_args > function in spawn.py. The following patch 'fixes' the quoting scheme. > This is the output from 'cvs diff spawn.py': > > Index: spawn.py > =================================================================== > RCS file: /cvsroot/python/distutils/distutils/spawn.py,v > retrieving revision 1.16 > diff -r1.16 spawn.py > 62,63c62 > < if string.find(args[i], ' ') != -1: > < args[i] = '"%s"' % args[i] > --- > >> args[i] = args[i].replace(' ','" "') Please no string methods until after we have released Python 2.3. String methods are not available in Python 1.5.2 which we still support. > > Instead of putting the whole space-containing argument into quotes, it > only quotes spaces. > > Unfortunately there is no reason for this not to break other > compilers. I think that this is a shell related problem, not so much a per program Due to infelicities in WinApi (child process gets the whole > command line, not split into arguments) it's up to the compiler/linker > to parse the command line and as far as I know there is no standard > way of encoding arguments that contain spaces. > > Now, the questions: > > 1. Can anyone test the above patch with other compilers? I only have > Borland. > > 2. I think that one 'standard' argument quoting function might not be > sufficient. Perhaps _nt_quote_args should be moved into CCompiler > class hierarchy? This way every compiler could override the standard > quoting function without the risk of breaking other compilers. > > 3. I have just started looking at the distutils source code and I am > not a Python guru, so perhaps there is another simple way to fix this > bug? > > Regards, > > Rafal Dowgird > > > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > http://mail.python.org/mailman/listinfo/distutils-sig -- 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/ From Rafal Dowgird Tue Dec 3 06:51:02 2002 From: Rafal Dowgird (Rafal Dowgird) Date: Tue Dec 3 06:51:02 2002 Subject: [Distutils] Re: Bug/patch question, WinNT, Borland C linker, spaces in paths In-Reply-To: <3DEC8B2D.8020406@lemburg.com> References: <184319639577.20021203110944@bms.com.pl> <3DEC8B2D.8020406@lemburg.com> Message-ID: <151325428601.20021203124613@bms.com.pl> Thanks for the reply. > Are you sure that it's worth adding quoting support for paths > with embedded spaces to distutils is worth the effort ? > I know that spaces in paths of executables and DLLs cause > endless problems on Windows and most of these can easily be > avoided by installing program files to a non-space-containing > path location on the disk. I am far from insisting that this patch should be applied. There are some simpler options that could improve the situation: - documenting it as a known bug with workaround - making distutils print a warning upon encountering a space in an argument What do you think? Of course, ignoring this is also possible. > Please no string methods until after we have released Python 2.3. > String methods are not available in Python 1.5.2 which we still > support. Sorry. As I have said, I have little knowledge of Python/distutils. Here is the patch without string methods: Index: spawn.py =================================================================== RCS file: /cvsroot/python/distutils/distutils/spawn.py,v retrieving revision 1.16 diff -r1.16 spawn.py 62,63c62 < if string.find(args[i], ' ') != -1: < args[i] = '"%s"' % args[i] --- > args[i] = string.replace(args[i],' ','" "') Regards, Rafal Dowgird From slash@dotnetslash.net Tue Dec 3 11:19:01 2002 From: slash@dotnetslash.net (Mark W. Alexander) Date: Tue Dec 3 11:19:01 2002 Subject: [Distutils] Bug/patch question, WinNT, Borland C linker, spaces in paths In-Reply-To: <3DEC8B2D.8020406@lemburg.com> Message-ID: On Tue, 3 Dec 2002, M.-A. Lemburg wrote: > Rafal Dowgird wrote: > > Hello, > > > > There is a bug in distutils that breaks Borland C linker. Distutils > > tries to pass search paths to the linker as > > "/LD:/Program Files/samplepath" > > Are you sure that it's worth adding quoting support for paths > with embedded spaces to distutils is worth the effort ? > > I know that spaces in paths of executables and DLLs cause > endless problems on Windows and most of these can easily be > avoided by installing program files to a non-space-containing > path location on the disk. Having battled spaces in user filenames constantly. I have concedeed that no matter how much I despise them, it's better to code assuming that there will _always_ be a space some where in the path. IMHO, it needs to be treated like a user input problem. Whether you want it to happen or not, it will, so code for it. mwa From R.Liebscher@gmx.de Wed Dec 4 02:46:01 2002 From: R.Liebscher@gmx.de (=?iso-8859-1?Q?Ren=E9?= Liebscher) Date: Wed Dec 4 02:46:01 2002 Subject: [Distutils] Re: Bug/patch question, WinNT, Borland C linker, spaces in paths References: <184319639577.20021203110944@bms.com.pl> <3DEC8B2D.8020406@lemburg.com> <151325428601.20021203124613@bms.com.pl> Message-ID: <3DEDB27C.B822F019@gmx.de> Rafal Dowgird schrieb: > > Thanks for the reply. > > > Are you sure that it's worth adding quoting support for paths > > with embedded spaces to distutils is worth the effort ? > > > I know that spaces in paths of executables and DLLs cause > > endless problems on Windows and most of these can easily be > > avoided by installing program files to a non-space-containing > > path location on the disk. > > I am far from insisting that this patch should be applied. There are > some simpler options that could improve the situation: > > - documenting it as a known bug with workaround > - making distutils print a warning upon encountering a space in an > argument I would suppose the following solution for _nt_quote_args: IF the given string doesn't contain any '"' THEN quote the whole string as usual ELSE leave it as it is. (Reason is: you would split then arguments. eg. a" "b would become "a" "b" ) With this solution all existing code should work as usual. And it is possible for any code using spawn/_nt_quote_args using its own quoting schema. (Which means for bcppcompiler.py fixing the link method.) Kind regards Rene Liebscher From ht@cogsci.ed.ac.uk Sat Dec 7 06:37:01 2002 From: ht@cogsci.ed.ac.uk (Henry S. Thompson) Date: Sat Dec 7 06:37:01 2002 Subject: [Distutils] Distutils for Python itself: compile, install and setup instructions for WIN32 Message-ID: I need a tk8.4 Python on a windows box, so I thought I'd install and build Python and compile _tkinter using tcl8.4. Silly me, I assumed if I compiled pythoncore and python, I could then use setup to do the rest. Not so -- various aspects of setup die, as follows: 1) Compile pythoncore and python using Visual C++ 6 and the supplied project files, under c:\Program Files\Python22; 2) Move python.exe and python.dll from c:\Program Files\Python22\PCbuild to c:\Program Files\Python22; 3) Try running python setup.py build in c:\Program Files\Python22 Dies because get_config_var("srcdir") returns [None]. Working around this gets me a bit further, then BINDIR needs a value, then a pervasive failure to locate pyconfig.h causes nothing to happen at great length. Should this work, and if so is there a cookbook description of how to make it work somewhere (I searched quite hard and failed to find it, sorry if it's staring me in the face somewhere). Another way to ask the question -- using configure+make on UN*X systems, distutils takes over early on and manages the rest. How do I achieve a similar installation on WIN32? Thanks in advance, ht -- Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh W3C Fellow 1999--2002, part-time member of W3C Team 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail really from me _always_ has this .sig -- mail without it is forged spam] From npat@inaccessnetworks.com Tue Dec 10 08:54:02 2002 From: npat@inaccessnetworks.com (Nick Patavalis) Date: Tue Dec 10 08:54:02 2002 Subject: [Distutils] Header dependencies when building extensions Message-ID: <20021210135338.GA31278@orion.priv.inaccessnetworks.com> Is there a way to specify (or even better, have "distutils" automatically deduce) header dependencies when building an extension? If, for example, the "foo" extension is built from "foo.c" which includes "foo.h", how can I make distutils rebuild the extension when "foo.h" changes? Thanks in advance /npat -- A commune is where people join together to share their lack of wealth. -- Richard M. Stallman From mps@viewbuild.com Tue Dec 10 21:36:03 2002 From: mps@viewbuild.com (Matthew Smith) Date: Tue Dec 10 21:36:03 2002 Subject: [Distutils] Linking to libs on MacOS X Message-ID: Hello, I'm having some difficulty extending python with a .cpp file and a library on Mac OS X 10.2.2 (I can't get distutils to find the library). The extention file (vbsecurity.cpp) file contains my the functions I am trying to make available to python, which needs to link to my library: libcryptopp.a (it's in the root of my distribution directory with the headers in a subdirectory - crypto42). The vbsecurity.cpp also makes use of a class (aesphm.cpp, aesphm.h). Now my setup.py file looks like the following: #!/usr/bin/env python from distutils.core import setup, Extension module1 = Extension('vbsecurity', sources = ['vbsecurity.cpp'], include_dirs=['crypto42'], #library_dirs=[''], libraries=['libcryptopp.a']) setup (name = 'vbsecurity', version = '1.0', ext_modules = [module1]) I've tried using library_dirs with an absolute path, placing the lib in a subdirectory and using a relative path, as well as placing the lib in '/usr/lib/'. And I get the following output: mps% python setup.py build running build running build_ext building 'vbsecurity' extension creating build creating build/temp.darwin-6.2-Power Macintosh-2.2 gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp -Icrypto42 -I/usr/include/python2.2 -c vbsecurity.cpp -o build/temp.darwin-6.2-Power Macintosh-2.2/vbsecurity.o [snip - some warnings] creating build/lib.darwin-6.2-Power Macintosh-2.2 gcc -arch i386 -arch ppc -bundle -flat_namespace -undefined suppress build/temp.darwin-6.2-Power Macintosh-2.2/vbsecurity.o -llibcryptopp.a -o build/lib.darwin-6.2-Power Macintosh-2.2/vbsecurity.so ld: for architecture i386 ld: warning /usr/lib/bundle1.o cputype (18, architecture ppc) does not match cputype (7) for specified -arch flag: i386 (file not loaded) ld: warning build/temp.darwin-6.2-Power Macintosh-2.2/vbsecurity.o cputype (18, architecture ppc) does not match cputype (7) for specified -arch flag: i386 (file not loaded) ld: can't locate file for: -llibcryptopp.a error: command 'gcc' failed with exit status 1 No matter what I've tried, I can't get it to find the library. Any help would be great... Cheers Matt From mps@viewbuild.com Tue Dec 10 22:00:02 2002 From: mps@viewbuild.com (Matthew Smith) Date: Tue Dec 10 22:00:02 2002 Subject: [Distutils] Linking to libs on MacOS X In-Reply-To: Message-ID: Me again, discovered that I need to specify the library as cryptopp, not libcryptopp.a (so it now compiles and links except for the i386 warnings). I've tried to test the module by navigating to the directory containing the vbsecurity.so file, launching the command line python and typing "import vbsecurity". This leads to the following error: Traceback (most recent call last): File "", line 1, in ? ImportError: Failure linking new module Any ideas?? Thanks, Matt > I'm having some difficulty extending python with a .cpp file and a library > on Mac OS X 10.2.2 (I can't get distutils to find the library). > > The extention file (vbsecurity.cpp) file contains my the functions I am > trying to make available to python, which needs to link to my library: > libcryptopp.a (it's in the root of my distribution directory with the > headers in a subdirectory - crypto42). > > The vbsecurity.cpp also makes use of a class (aesphm.cpp, aesphm.h). > > Now my setup.py file looks like the following: > > > > #!/usr/bin/env python > > from distutils.core import setup, Extension > > module1 = Extension('vbsecurity', > sources = ['vbsecurity.cpp'], > include_dirs=['crypto42'], > #library_dirs=[''], > libraries=['libcryptopp.a']) > > setup (name = 'vbsecurity', version = '1.0', ext_modules = [module1]) > > > I've tried using library_dirs with an absolute path, placing the lib in a > subdirectory and using a relative path, as well as placing the lib in > '/usr/lib/'. > > > > And I get the following output: > > > > mps% python setup.py build > running build > running build_ext > building 'vbsecurity' extension > creating build > creating build/temp.darwin-6.2-Power Macintosh-2.2 > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp -Icrypto42 > -I/usr/include/python2.2 -c vbsecurity.cpp -o build/temp.darwin-6.2-Power > Macintosh-2.2/vbsecurity.o > > [snip - some warnings] > > creating build/lib.darwin-6.2-Power Macintosh-2.2 > gcc -arch i386 -arch ppc -bundle -flat_namespace -undefined suppress > build/temp.darwin-6.2-Power Macintosh-2.2/vbsecurity.o -llibcryptopp.a -o > build/lib.darwin-6.2-Power Macintosh-2.2/vbsecurity.so > ld: for architecture i386 > ld: warning /usr/lib/bundle1.o cputype (18, architecture ppc) does not match > cputype (7) for specified -arch flag: i386 (file not loaded) > ld: warning build/temp.darwin-6.2-Power Macintosh-2.2/vbsecurity.o cputype > (18, architecture ppc) does not match cputype (7) for specified -arch flag: > i386 (file not loaded) > ld: can't locate file for: -llibcryptopp.a > error: command 'gcc' failed with exit status 1 > > > > No matter what I've tried, I can't get it to find the library. > > Any help would be great... > > Cheers > > Matt > > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > http://mail.python.org/mailman/listinfo/distutils-sig > From Andrew.Gregory@npl.co.uk Wed Dec 11 08:57:13 2002 From: Andrew.Gregory@npl.co.uk (Andrew Gregory) Date: Wed Dec 11 08:57:13 2002 Subject: [Distutils] Compiling Python C++ extensions with MingW Message-ID: <8B3E03343914D411A51000062938C79602B0A023@golf.npl.co.uk> I posted details of a problems on the google Python user group - someone emailed to say that I should send this to the distutils-sig. mailing list. It concerns compiling a very simple C++ extension (as a test) on Mingw 2.0.0 for use with MSVC-compiled Python. Using linker option --enable-cxx did not help. http://groups.google.co.uk/groups?dq=&hl=en&lr=&ie=UTF-8&threadm=2830c89 c.0212101559.6ea63560%40posting.google.com&prev=/groups%3Fhl%3Den%26lr%3 D%26ie%3DUTF-8%26group%3Dcomp.lang.python The output is shown below. The SWIG warnings seem to be normal - but it failed at the dllwrap stage. Andrew Gregory. C:\PyFiles\exMingw\MyCPP>python setup.py build --compiler=mingw32 running build running build_ext building '_pysimple' extension creating build creating build\temp.win32-2.2 creating build\temp.win32-2.2\Release C:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -IC:\Python22\include -c pysimple_wrap.cxx -o build\temp.win32-2.2\Relea se\pysimple_wrap.o pysimple_wrap.cxx:180: warning: `swig_type_info* SWIG_TypeDynamicCast(swig_type_info*, void**)' defined but not used pysimple_wrap.cxx:192: warning: `swig_type_info* SWIG_TypeQuery(const char*)' defined but not used pysimple_wrap.cxx:374: warning: `void SWIG_addvarlink(PyObject*, char*, PyObject*(*)(), int (*)(PyObject*))' defined but not used pysimple_wrap.cxx:427: warning: `int SWIG_ConvertPtr(PyObject*, void**, swig_type_info*, int)' defined but not used pysimple_wrap.cxx:519: warning: `int SWIG_ConvertPacked(PyObject*, void*, int, swig_type_info*, int)' defined but not used writing build\temp.win32-2.2\Release\_pysimple.def creating build\lib.win32-2.2 C:\MinGW\bin\dllwrap.exe -mno-cygwin -mdll -static --entry _DllMain@12 --output-lib build\temp.win32-2.2\Release\lib_pys imple.a --def build\temp.win32-2.2\Release\_pysimple.def -s build\temp.win32-2.2\Release\pysimple_wrap.o -LC:\Python22\l ibs -lpython22 -o build\lib.win32-2.2\_pysimple.pyd build\temp.win32-2.2\Release\pysimple_wrap.o(.eh_frame+0x11):pysimple_wr ap.cxx: undefined reference to `__gxx_personalit y_v0' dllwrap: gcc exited with status 1 error: command 'dllwrap' failed with exit status 1 ------------------------------------------------------------------- This e-mail and any attachments may contain confidential and/or privileged material; it is for the intended addressee(s) only. If you are not a named addressee, you must not use, retain or disclose such information. NPL Management Ltd cannot guarantee that the e-mail or any attachments are free from viruses. NPL Management Ltd. Registered in England and Wales. No: 2937881 Registered Office: Teddington, Middlesex, United Kingdom TW11 0LW. ------------------------------------------------------------------- From mal@lemburg.com Wed Dec 11 13:27:09 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed Dec 11 13:27:09 2002 Subject: [Distutils] Compiling Python C++ extensions with MingW References: <8B3E03343914D411A51000062938C79602B0A023@golf.npl.co.uk> Message-ID: <3DF78350.2000908@lemburg.com> Andrew Gregory wrote: > I posted details of a problems on the google Python user group - someone > emailed to say that I should send this to the distutils-sig. mailing > list. > > It concerns compiling a very simple C++ extension (as a test) on Mingw > 2.0.0 for use with MSVC-compiled Python. Using linker option > --enable-cxx did not help. > > http://groups.google.co.uk/groups?dq=&hl=en&lr=&ie=UTF-8&threadm=2830c89 > c.0212101559.6ea63560%40posting.google.com&prev=/groups%3Fhl%3Den%26lr%3 > D%26ie%3DUTF-8%26group%3Dcomp.lang.python > > The output is shown below. The SWIG warnings seem to be normal - but it > failed at the dllwrap stage. > > Andrew Gregory. > > > C:\PyFiles\exMingw\MyCPP>python setup.py build --compiler=mingw32 > running build > running build_ext > building '_pysimple' extension > creating build > creating build\temp.win32-2.2 > creating build\temp.win32-2.2\Release > C:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -IC:\Python22\include -c > pysimple_wrap.cxx -o build\temp.win32-2.2\Relea > se\pysimple_wrap.o > pysimple_wrap.cxx:180: warning: `swig_type_info* > SWIG_TypeDynamicCast(swig_type_info*, void**)' defined but not used > pysimple_wrap.cxx:192: warning: `swig_type_info* SWIG_TypeQuery(const > char*)' > defined but not used > pysimple_wrap.cxx:374: warning: `void SWIG_addvarlink(PyObject*, char*, > PyObject*(*)(), int (*)(PyObject*))' defined but not used > pysimple_wrap.cxx:427: warning: `int SWIG_ConvertPtr(PyObject*, void**, > swig_type_info*, int)' defined but not used > pysimple_wrap.cxx:519: warning: `int SWIG_ConvertPacked(PyObject*, > void*, int, > swig_type_info*, int)' defined but not used > writing build\temp.win32-2.2\Release\_pysimple.def > creating build\lib.win32-2.2 > C:\MinGW\bin\dllwrap.exe -mno-cygwin -mdll -static --entry _DllMain@12 > --output-lib build\temp.win32-2.2\Release\lib_pys > imple.a --def build\temp.win32-2.2\Release\_pysimple.def -s > build\temp.win32-2.2\Release\pysimple_wrap.o -LC:\Python22\l > ibs -lpython22 -o build\lib.win32-2.2\_pysimple.pyd > build\temp.win32-2.2\Release\pysimple_wrap.o(.eh_frame+0x11):pysimple_wr > ap.cxx: undefined reference to `__gxx_personalit > y_v0' > dllwrap: gcc exited with status 1 > error: command 'dllwrap' failed with exit status 1 Looks like some lib is missing. Hard to tell which without a working MinGW installed :-) -- 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/ From dave@boost-consulting.com Wed Dec 11 13:56:00 2002 From: dave@boost-consulting.com (David Abrahams) Date: Wed Dec 11 13:56:00 2002 Subject: [Distutils] Compiling Python C++ extensions with MingW In-Reply-To: <3DF78350.2000908@lemburg.com> ("M.-A. Lemburg"'s message of "Wed, 11 Dec 2002 19:26:24 +0100") References: <8B3E03343914D411A51000062938C79602B0A023@golf.npl.co.uk> <3DF78350.2000908@lemburg.com> Message-ID: "M.-A. Lemburg" writes: >> ap.cxx: undefined reference to `__gxx_personalit >> y_v0' >> dllwrap: gcc exited with status 1 >> error: command 'dllwrap' failed with exit status 1 > > Looks like some lib is missing. Hard to tell which without > a working MinGW installed :-) That's not just "some lib", but a part of the C++ runtime. It may be as simple as setting LD_LIBRARY_PATH to include the location of the C++ runtimes shipped with mingw when linking. -- David Abrahams dave@boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution From Norman Vine" <3DF78350.2000908@lemburg.com> Message-ID: <039a01c2a147$f0789720$1d6cba8c@sfdev3> M.-A. Lemburg wrote > > Andrew Gregory wrote: > > I posted details of a problems on the google Python user group - someone > > emailed to say that I should send this to the distutils-sig. mailing > > list. > > > > It concerns compiling a very simple C++ extension (as a test) on Mingw > > 2.0.0 for use with MSVC-compiled Python. Using linker option > > --enable-cxx did not help. > > > > http://groups.google.co.uk/groups?dq=&hl=en&lr=&ie=UTF-8&threadm=2830c89 > > c.0212101559.6ea63560%40posting.google.com&prev=/groups%3Fhl%3Den%26lr%3 > > D%26ie%3DUTF-8%26group%3Dcomp.lang.python > > > > The output is shown below. The SWIG warnings seem to be normal - but it > > failed at the dllwrap stage. > > > > Andrew Gregory. > > > > C:\MinGW\bin\dllwrap.exe -mno-cygwin -mdll -static --entry _DllMain@12 > > --output-lib build\temp.win32-2.2\Release\lib_pysimple.a >> --def build\temp.win32-2.2\Release\_pysimple.def -s > > build\temp.win32-2.2\Release\pysimple_wrap.o >> -LC:\Python22\libs -lpython22 -o build\lib.win32-2.2\_pysimple.pyd > > build\temp.win32-2.2\Release\pysimple_wrap.o(.eh_frame+0x11): >> pysimple_wrap.cxx: undefined reference to `__gxx_personality_v0' > Looks like some lib is missing. Hard to tell which without > a working MinGW installed :-) try adding -lsupc++ to the linked with libs if that doesn't work try -lstdc++ HTH Norman From akuchlin@mems-exchange.org Wed Dec 11 16:22:13 2002 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Wed Dec 11 16:22:13 2002 Subject: [Distutils] Header dependencies when building extensions In-Reply-To: <20021210135338.GA31278@orion.priv.inaccessnetworks.com> References: <20021210135338.GA31278@orion.priv.inaccessnetworks.com> Message-ID: <20021211212053.GB30485@ute.mems-exchange.org> On Tue, Dec 10, 2002 at 03:53:38PM +0200, Nick Patavalis wrote: >If, for example, the "foo" extension is built from "foo.c" which >includes "foo.h", how can I make distutils rebuild the extension when >"foo.h" changes? Python 2.3 CVS has a 'depends' argument for specifying additional dependencies; something like: Extension('foo', ['foomodule.c'], depends = ['foo.h']) This is a new feature, so it probably won't be back-ported to Python 2.2. --amk From mal@lemburg.com Wed Dec 11 16:43:01 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed Dec 11 16:43:01 2002 Subject: [Distutils] Compiling Python C++ extensions with MingW References: <8B3E03343914D411A51000062938C79602B0A023@golf.npl.co.uk> <3DF78350.2000908@lemburg.com> Message-ID: <3DF7B10A.8020205@lemburg.com> David Abrahams wrote: > "M.-A. Lemburg" writes: > > >>>ap.cxx: undefined reference to `__gxx_personalit >>>y_v0' >>>dllwrap: gcc exited with status 1 >>>error: command 'dllwrap' failed with exit status 1 >> >>Looks like some lib is missing. Hard to tell which without >>a working MinGW installed :-) > > > That's not just "some lib", but a part of the C++ runtime. It may be > as simple as setting LD_LIBRARY_PATH to include the location of the > C++ runtimes shipped with mingw when linking. Patches are welcome. AFAIK, nobody is supporting MinGW for distutils, so you're on your own here. Could be that g++ needs to be used instead of gcc for compiling C++ code... at least that's what the CVS log suggests. The MinGW class has gcc hard-coded... -- 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/ From dave@boost-consulting.com Wed Dec 11 16:51:24 2002 From: dave@boost-consulting.com (David Abrahams) Date: Wed Dec 11 16:51:24 2002 Subject: [Distutils] Compiling Python C++ extensions with MingW In-Reply-To: <3DF7B10A.8020205@lemburg.com> ("M.-A. Lemburg"'s message of "Wed, 11 Dec 2002 22:41:30 +0100") References: <8B3E03343914D411A51000062938C79602B0A023@golf.npl.co.uk> <3DF78350.2000908@lemburg.com> <3DF7B10A.8020205@lemburg.com> Message-ID: "M.-A. Lemburg" writes: > David Abrahams wrote: >> "M.-A. Lemburg" writes: >> >>>>ap.cxx: undefined reference to `__gxx_personalit >>>>y_v0' >>>>dllwrap: gcc exited with status 1 >>>>error: command 'dllwrap' failed with exit status 1 >>> >>>Looks like some lib is missing. Hard to tell which without >>>a working MinGW installed :-) >> That's not just "some lib", but a part of the C++ runtime. It may be >> as simple as setting LD_LIBRARY_PATH to include the location of the >> C++ runtimes shipped with mingw when linking. > > Patches are welcome. AFAIK, nobody is supporting MinGW for distutils, > so you're on your own here. > > Could be that g++ needs to be used instead of gcc for compiling > C++ code... Yes, that is definitely the case. > at least that's what the CVS log suggests. The MinGW class has gcc > hard-coded... Easy fix, then! -- David Abrahams dave@boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution From krjackson@lbl.gov Wed Dec 11 17:37:23 2002 From: krjackson@lbl.gov (Keith Jackson (DSD staff)) Date: Wed Dec 11 17:37:23 2002 Subject: [Distutils] overriding build options Message-ID: <3DF7BDA3.4010308@lbl.gov> Hi, I've got what might be a simple question, but I haven't found an answer yet. The default python build with gcc uses "-Wall" and "-fstrict-prototypes". I'd like to be able to build extension modules without these flags. SWIG generated code throws a lot of warnings, as does the libraries I'm wrapping, and it makes it very hard for users to see what is actually going on. What is the right way to remove these from the compile command? thanks in advance, --keith ---------------------------------------------------------------- Keith R. Jackson KRJackson@lbl.gov Secure Grid Technologies Group (510) 486-4401 Lawrence Berkeley National Laboratory http://www-itg.lbl.gov/~kjackson/ From mal@lemburg.com Wed Dec 11 17:55:01 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed Dec 11 17:55:01 2002 Subject: [Distutils] overriding build options References: <3DF7BDA3.4010308@lbl.gov> Message-ID: <3DF7C210.5040700@lemburg.com> Keith Jackson (DSD staff) wrote: > Hi, > I've got what might be a simple question, but I haven't found an answer > yet. The default python build with gcc uses "-Wall" and > "-fstrict-prototypes". I'd like to be able to build extension modules > without these flags. SWIG generated code throws a lot of warnings, as > does the libraries I'm wrapping, and it makes it very hard for users to > see what is actually going on. What is the right way to remove these > from the compile command? AFAIK, there is none. These options are read from Python's own Makefile in sysconfig.customize_compiler(compiler). Of course, you can start subclassing distutils as I did in mxSetup.py of the egenix-mx-base package to tweak that API into doing whatever you like :-) -- 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/ From krjackson@lbl.gov Wed Dec 11 18:46:03 2002 From: krjackson@lbl.gov (Keith Jackson (DSD staff)) Date: Wed Dec 11 18:46:03 2002 Subject: [Distutils] overriding build options References: <3DF7BDA3.4010308@lbl.gov> <3DF7C210.5040700@lemburg.com> Message-ID: <3DF7CE22.50207@lbl.gov> That's what I was afraid of. It sure seems like a simple way to override the compile options from the python build would be nice. --keith M.-A. Lemburg wrote: > > Keith Jackson (DSD staff) wrote: > >> Hi, >> I've got what might be a simple question, but I haven't found an >> answer yet. The default python build with gcc uses "-Wall" and >> "-fstrict-prototypes". I'd like to be able to build extension modules >> without these flags. SWIG generated code throws a lot of warnings, as >> does the libraries I'm wrapping, and it makes it very hard for users >> to see what is actually going on. What is the right way to remove >> these from the compile command? > > > AFAIK, there is none. These options are read from Python's own > Makefile in sysconfig.customize_compiler(compiler). > > Of course, you can start subclassing distutils as I did in > mxSetup.py of the egenix-mx-base package to tweak that API > into doing whatever you like :-) > -- ---------------------------------------------------------------- Keith R. Jackson KRJackson@lbl.gov Secure Grid Technologies Group (510) 486-4401 Lawrence Berkeley National Laboratory http://www-itg.lbl.gov/~kjackson/ From mwh@python.net Thu Dec 12 05:47:11 2002 From: mwh@python.net (Michael Hudson) Date: Thu Dec 12 05:47:11 2002 Subject: [Distutils] overriding build options In-Reply-To: "Keith Jackson's message of "Wed, 11 Dec 2002 15:45:38 -0800" References: <3DF7BDA3.4010308@lbl.gov> <3DF7C210.5040700@lemburg.com> <3DF7CE22.50207@lbl.gov> Message-ID: <2m1y4npl9c.fsf@starship.python.net> "Keith Jackson (DSD staff)" writes: > That's what I was afraid of. It sure seems like a simple way to override > the compile options from the python build would be nice. Would be nice, yes, but also a bit of a minefield: generally extension modules have to be built with the same options as Python or all hell can break loose (here I'm thinking particularly of large file options). Obviously, this doesn't apply to warning options, but... brr. There's also x-platform considerations here. Cheers, M. -- Well, yes. I don't think I'd put something like "penchant for anal play" and "able to wield a buttplug" in a CV unless it was relevant to the gig being applied for... -- Matt McLeod, alt.sysadmin.recovery From Juergen Hermann" Message-ID: On Wed, 11 Dec 2002 14:35:15 -0800, Keith Jackson (DSD staff) wrote: >I've got what might be a simple question, but I haven't found an answer= >yet. The default python build with gcc uses "-Wall" and >"-fstrict-prototypes". I'd like to be able to build extension modules >without these flags. SWIG generated code throws a lot of warnings, as >does the libraries I'm wrapping, and it makes it very hard for users to= >see what is actually going on. What is the right way to remove these >from the compile command? A quick and quite dirty way is this: from distutils import sysconfig cv =3D sysconfig.get_config_vars() cv["OPT"] =3D cv["OPT"].replace("-O3", "") Call this before calling setup(). And yes, you will burn in hell for it! :) Ciao, J=FCrgen -- J=FCrgen Hermann, Developer WEB.DE AG, http://webde-ag.de/ From Andrew.Gregory@npl.co.uk Fri Dec 13 15:02:01 2002 From: Andrew.Gregory@npl.co.uk (Andrew Gregory) Date: Fri Dec 13 15:02:01 2002 Subject: [Distutils] Compiling Python C++ extensions with MingW Message-ID: <8B3E03343914D411A51000062938C79602B0A025@golf.npl.co.uk> Thanks for the reply. I had not realised that distutils does not support Mingw when compiling C++ I searched for "gxx_personality" in files (using find). It's in libstdc++.a and libsubc++.a which are in the directory C:\MinGW\bin As soon as I've got time I'll have another go, but linking to these files. Andrew Gregory. > -----Original Message----- > From: David Abrahams [mailto:dave@boost-consulting.com] > Sent: 11 December 2002 21:50 > To: M.-A. Lemburg > Cc: Andrew Gregory; 'distutils-sig@python.org' > Subject: Re: [Distutils] Compiling Python C++ extensions with MingW > > > "M.-A. Lemburg" writes: > > > David Abrahams wrote: > >> "M.-A. Lemburg" writes: > >> > >>>>ap.cxx: undefined reference to `__gxx_personalit > >>>>y_v0' > >>>>dllwrap: gcc exited with status 1 > >>>>error: command 'dllwrap' failed with exit status 1 > >>> > >>>Looks like some lib is missing. Hard to tell which without > >>>a working MinGW installed :-) > >> That's not just "some lib", but a part of the C++ runtime. > It may be > >> as simple as setting LD_LIBRARY_PATH to include the location of the > >> C++ runtimes shipped with mingw when linking. > > > > Patches are welcome. AFAIK, nobody is supporting MinGW for > distutils, > > so you're on your own here. > > > > Could be that g++ needs to be used instead of gcc for compiling > > C++ code... > > Yes, that is definitely the case. > > > at least that's what the CVS log suggests. The MinGW class has gcc > > hard-coded... > > Easy fix, then! > > -- > David Abrahams > dave@boost-consulting.com * http://www.boost-consulting.com > Boost support, enhancements, training, and commercial distribution > ------------------------------------------------------------------- This e-mail and any attachments may contain confidential and/or privileged material; it is for the intended addressee(s) only. If you are not a named addressee, you must not use, retain or disclose such information. NPL Management Ltd cannot guarantee that the e-mail or any attachments are free from viruses. NPL Management Ltd. Registered in England and Wales. No: 2937881 Registered Office: Teddington, Middlesex, United Kingdom TW11 0LW. ------------------------------------------------------------------- From Andrew.Gregory@npl.co.uk Sat Dec 14 12:23:02 2002 From: Andrew.Gregory@npl.co.uk (Andrew Gregory) Date: Sat Dec 14 12:23:02 2002 Subject: [Distutils] Compiling Python C++ extensions with MingW Message-ID: <8B3E03343914D411A51000062938C79602B0A026@golf.npl.co.uk> Apologies for troubling you all, the solution is quite simple. You just need to include library stdc++. I'll post something on the newsgroup. The setup.py file looks like: # setup.py - for building _pysimple.pyd # # To use, from command line type: # python setup.py build --compiler=mingw32 # # or python setup.py build --compiler=bcpp # # If sources=['pysimple.i'] then SWIG will be called # but do not yet know how to set SWIG options. # from distutils.core import setup, Extension setup (name = "_pysimple", version = "1.0", maintainer = "Andrew Gregory", maintainer_email = "andrew.gregory@npl.co.uk", description = "Sample Python DLL", ext_modules = [Extension('_pysimple', library_dirs=['C:\\mingw\\lib'], libraries=['stdc++'], sources=['pysimple_wrap.cxx'])]) Suggestion: a future release of distutils might do this automatically for mingw when the source extension is .cpp, .cc or .cxx? Andrew Gregory. > -----Original Message----- > From: David Abrahams [mailto:dave@boost-consulting.com] > Sent: 11 December 2002 21:50 > To: M.-A. Lemburg > Cc: Andrew Gregory; 'distutils-sig@python.org' > Subject: Re: [Distutils] Compiling Python C++ extensions with MingW > > > "M.-A. Lemburg" writes: > > > David Abrahams wrote: > >> "M.-A. Lemburg" writes: > >> > >>>>ap.cxx: undefined reference to `__gxx_personalit > >>>>y_v0' > >>>>dllwrap: gcc exited with status 1 > >>>>error: command 'dllwrap' failed with exit status 1 > >>> > >>>Looks like some lib is missing. Hard to tell which without > >>>a working MinGW installed :-) > >> That's not just "some lib", but a part of the C++ runtime. > It may be > >> as simple as setting LD_LIBRARY_PATH to include the location of the > >> C++ runtimes shipped with mingw when linking. > > > > Patches are welcome. AFAIK, nobody is supporting MinGW for > distutils, > > so you're on your own here. > > > > Could be that g++ needs to be used instead of gcc for compiling > > C++ code... > > Yes, that is definitely the case. > > > at least that's what the CVS log suggests. The MinGW class has gcc > > hard-coded... > > Easy fix, then! > > -- > David Abrahams > dave@boost-consulting.com * http://www.boost-consulting.com > Boost support, enhancements, training, and commercial distribution > ------------------------------------------------------------------- This e-mail and any attachments may contain confidential and/or privileged material; it is for the intended addressee(s) only. If you are not a named addressee, you must not use, retain or disclose such information. NPL Management Ltd cannot guarantee that the e-mail or any attachments are free from viruses. NPL Management Ltd. Registered in England and Wales. No: 2937881 Registered Office: Teddington, Middlesex, United Kingdom TW11 0LW. ------------------------------------------------------------------- From Jack.Jansen@cwi.nl Mon Dec 16 06:16:01 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Mon Dec 16 06:16:01 2002 Subject: [Distutils] lineendings In-Reply-To: <3DAC729A.10603@lemburg.com> Message-ID: On Tuesday, Oct 15, 2002, at 21:55 Europe/Amsterdam, M.-A. Lemburg wrote: >> well it certainly does in python-2.2.2 and there's pep 278 which seems >> to be concerned as well. >> Try entering import a, \ >> b >> in mac format and then execute on a windows box. I see the following >> C:\>\tmp\ttt.py >> File "C:\tmp\ttt.py", line 1 >> rlextrareportlab,\ >> ^ >> SyntaxError: invalid token > > Interesting. That must be related to Macs only, though, because > I move around between Windows and Unix on a regular basis and > have so far never had any problem with line ends. If Python 2.2 and later are the only platforms of interest then you can use unix lineendings, and all Pythons will be happy. MacPython 2.2 has a "poor mans universal newlines" feature, where it recognizes unix lineendings (but *not* windows lineendings) on any text file. And 2.3 has universal newline support on all platforms. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Juergen Hermann" Message-ID: On Sat, 14 Dec 2002 17:22:03 -0000, Andrew Gregory wrote: >Apologies for troubling you all, the solution is quite simple. You just= >need to include library stdc++. Generally, I guess this is not enough, you HAVE to link using g++ instea= d of ld when using templates, for example. Ciao, J=FCrgen -- J=FCrgen Hermann, Developer WEB.DE AG, http://webde-ag.de/ From jeremy@alum.mit.edu Thu Dec 19 14:42:19 2002 From: jeremy@alum.mit.edu (Jeremy Hylton) Date: Thu Dec 19 14:42:19 2002 Subject: [Distutils] meaning of -i option to build Message-ID: <15874.8389.376047.724452@slothrop.zope.com> The short documentation blurb for the -i option says: ignore build-lib and put compiled extensions into the source directory alongside your pure Python modules I tried to write an Extension() where the name of the extension did not match exactly the source directory. Say the extension is called A.B and its source is in src/A/B.c. IOW Extension("A.B", ["src/A/B.c"]) If I run setup.py build_ext -i, then distutils creates an A directory parallel to src and installs A/B.so. That doesn't match the documentation, since it isn't in the same location as the source. Some specific questions about this behavior: Is it intended? If so, then it's a doc bug. Is there a better way to write my setup.py so that I don't run into this behavior directly, e.g. an option to setup() that specifies the source directory (similar to the packages_dir)? Jeremy From jeremy@alum.mit.edu Thu Dec 19 18:37:02 2002 From: jeremy@alum.mit.edu (Jeremy Hylton) Date: Thu Dec 19 18:37:02 2002 Subject: [Distutils] installing header files in directories Message-ID: <15874.22472.946482.92730@slothrop.zope.com> Is there some way to get a header file installed in a subdirectory? Zope3 has code that looks like this: #include "Zope/Proxy/proxy.h" I don't know how to ask distutils to create /usr/local/include/python2.x/Zope/Proxy/proxy.h The only thing it seems willing to do is create a single directory inside include/python2.x and place all my .h files there. Jeremy From mdehoon@ims.u-tokyo.ac.jp Fri Dec 20 00:22:02 2002 From: mdehoon@ims.u-tokyo.ac.jp (Michiel Jan Laurens de Hoon) Date: Fri Dec 20 00:22:02 2002 Subject: [Distutils] python setup.py config glitches Message-ID: <3E02A98E.1000908@ims.u-tokyo.ac.jp> Dear pythoneers, I am using distutils for a scientific plotting package for python. Recently I added the configuration part of the installation process to setup.py (previously, it was done with a 'make config'). My setup.py now looks like ... from distutils.command.config import config ... class my_config (config): def run (self): self.configthis() self.configthat() ... def configthis(self): ... def configthat(self): ... ... setup( ... cmdclass = {'config': my_config}, ... ) This all works, except for a few glitches (running Python 2.2.2): 1) On Cygwin, 'python setup.py config' tries to run the cc compiler, instead of the gcc compiler. By adding --compiler=cygwin, I can force it to use the gcc compiler and everything works, but this should not be necessary. When executing 'python setup.py build', I don't need to specify --compiler=cygwin, distutils chooses gcc automatically. 2) On Linux, I get an error message from distutils/command/config.py line 155: prog = prog + self.compiler.exe_extension TypeError: cannot concatenate 'str' and 'NoneType' objects The problem here is that on Linux, self.compiler.exe_extension is None, and python does not allow None to be concatenated with a string. If self.compiler.exe_extension would be "", it would work. 3) Running 'python setup.py config' produces a lot of output, such that a user would probably miss an error or warning message. Is there a way to reduce the amount of output by default? Such that a user who simple-mindedly runs 'python setup.py config' sees the important information only? Any help will be appreciated. I apologize if these are known issues. --Michiel. -- Michiel de Hoon, Assistant Professor University of Tokyo, Institute of Medical Science Human Genome Center 4-6-1 Shirokane-dai, Minato-ku Tokyo 108-8639 Japan http://bonsai.ims.u-tokyo.ac.jp/~mdehoon From tlau-distutils@ofb.net Fri Dec 20 13:09:01 2002 From: tlau-distutils@ofb.net (Tessa Lau) Date: Fri Dec 20 13:09:01 2002 Subject: [Distutils] install-data and finding the installed files Message-ID: <19299.1040407701@ofb.net> I'm distributing a Python application which has to install and use a data file. In my setup.py I include the following option: setup (name = "MyProg", ... data_files = [('config', ['data.rc'])], scripts = ['doit'], ... ) When I run "setup.py install --prefix=/foo/bar", setup will copy my data file to /foo/bar/config/data.rc. However my Python program needs to know how to find that file. How does the "doit" script find out the installation directory so that it can compute the absolute path to the data.rc file? Thanks, --Tessa From krjackson@lbl.gov Mon Dec 30 15:57:44 2002 From: krjackson@lbl.gov (Keith Jackson) Date: Mon Dec 30 15:57:44 2002 Subject: [Distutils] swig 1.3.x Message-ID: <3E10B2F4.7090901@lbl.gov> 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 From amk@amk.ca Mon Dec 30 19:23:33 2002 From: amk@amk.ca (A.M. Kuchling) Date: Mon Dec 30 19:23:33 2002 Subject: [Distutils] swig 1.3.x In-Reply-To: <3E10B2F4.7090901@lbl.gov>; from krjackson@lbl.gov on Mon, Dec 30, 2002 at 12:56:20PM -0800 References: <3E10B2F4.7090901@lbl.gov> Message-ID: <20021230193344.A22144@nyman.amk.ca> 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 From lists@morpheus.demon.co.uk Tue Dec 31 14:13:06 2002 From: lists@morpheus.demon.co.uk (Paul Moore) Date: Tue Dec 31 14:13:06 2002 Subject: [Distutils] swig 1.3.x References: <3E10B2F4.7090901@lbl.gov> Message-ID: 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. Paul. -- This signature intentionally left blank