Hi folks, Over on the vpython-users mailing list I've been trying to get help with VPython's complicated autoconf-based setup, which turns out to be fairly broken for OS X. They realize that the current setup is too complex and are looking at other options. The following is an exerpt from the ongoing discussion:
On Wed, 2005-10-19 at 21:06 -0700, Dethe Elza wrote:
On 19-Oct-05, at 4:57 PM, Jonathan Brandmeyer wrote:
Are you (or anyone else out there) familiar with Scons?
What is wrong with using distutils[1], the standard method for building Python extensions? The new Setuptools[2] package makes it even easier, and supports EasyInstall[3] and Python Eggs[4].
[1] http://docs.python.org/lib/module-distutils.html [2] http://peak.telecommunity.com/DevCenter/setuptools [3] http://peak.telecommunity.com/DevCenter/EasyInstall [4] http://peak.telecommunity.com/DevCenter/PythonEggs
But it doesn't properly support C++, or the use of a compiler other than the one that built Python itself. Those features are absolutely required for VPython.
-Jonathan
I'm not a distutils/setuptools expert (though I'm willing and eager to become one rather than struggle with autoconf any further), but can anyone tell me if Jonathan's statement is even true? I'm willing to create a parallel setuptools-based builder just for OS X use, since the same compiler problem isn't an issue on OS X, but can I use distutils with C++ code? Thanks! --Dethe
At 03:46 PM 11/3/2005 -0800, Dethe Elza wrote:
But it doesn't properly support C++, or the use of a compiler other than the one that built Python itself. Those features are absolutely required for VPython.
-Jonathan
I'm not a distutils/setuptools expert (though I'm willing and eager to become one rather than struggle with autoconf any further), but can anyone tell me if Jonathan's statement is even true?
I'm willing to create a parallel setuptools-based builder just for OS X use, since the same compiler problem isn't an issue on OS X, but can I use distutils with C++ code?
As far as I know, yes. I don't know what is meant by "properly support C++", though. If the meaning is "support static initializers when Python was not built with a C++ compiler and runtime", then that statement might be correct, but if that is the issue then no other method of building (short of rebuilding the Python executable) would fix the problem anyway, and distutils is neither the problem nor the solution in that case. As for the "use of a compiler other than the one that built Python itself", that's not correct either. For example, it is common to build Python extensions for Windows using distutils and the MinGW compiler, even though Python itself is built with Visual C++. Also, it's possible to get the distutils to build using the freeware version of Visual C++ as well. Alas, I am not an OS X or C++ expert, so I'm unlikely to be able to give you much guidance, other than pointing you to the distutils docs: http://docs.python.org/ext/building.html As far as I'm aware, it should be sufficient to list the C++ (.cpp) files in 'sources', and to specify the various libraries, defines, etc. as shown on the page above. (Creating a useful cross-platform setup.py will of course require conditional code to change the libraries, macros, or other values as appropriate.)
Thanks, Phillip. You've confirmed what I thought, the next step is for me to dig in and try it. --Dethe "Computers are beyond dumb, they're mind-numbingly stupid. They're hostile, rigid, capricious, and unforgiving. They're impossibly demanding and they never learn anything." -- John R. Levine
Phillip J. Eby wrote:
As for the "use of a compiler other than the one that built Python itself", that's not correct either. For example, it is common to build Python extensions for Windows using distutils and the MinGW compiler, even though Python itself is built with Visual C++. Also, it's possible to get the distutils to build using the freeware version of Visual C++ as well.
Unfortunately there is a good deal of outdated information on the web that lists all sorts of hoops one needs to jump through to support a compiler such as MinGW. Or rather, used to have to jump through. Things are much easier now. Take Qt for example. Most people still refer to a webpage that lists lots of steps that are no longer needed, at least not with Python 2.4. -- Patrick K. O'Brien Orbtech http://www.orbtech.com Schevo http://www.schevo.org
At 07:08 PM 11/3/2005 -0500, Phillip J. Eby wrote:
As far as I know, yes. I don't know what is meant by "properly support C++", though. If the meaning is "support static initializers when Python was not built with a C++ compiler and runtime", then that statement might be correct, but if that is the issue then no other method of building (short of rebuilding the Python executable) would fix the problem anyway, and distutils is neither the problem nor the solution in that case.
A follow up on this... it appears that "proper support for C++" was implemented in the distutils about 2 years ago, and has been distributed with Python since version 2.3: http://svn.python.org/view/python/trunk/Lib/distutils/command/build_ext.py?rev=29513&view=markup If I understand this link correctly, no special actions are needed to build C++ extension modules with the distutils; just list 'em and go. Of course, if you're still using 2.2 (like Google), you're probably out of luck on this issue.
On 3-Nov-05, at 4:56 PM, Phillip J. Eby wrote:
If I understand this link correctly, no special actions are needed to build C++ extension modules with the distutils; just list 'em and go.
Excellent, I'll try it and let you know.
Of course, if you're still using 2.2 (like Google), you're probably out of luck on this issue.
No, using 2.4 is the goal. --Dethe "Well I've wrestled with reality for thirty-five years now, doctor, and I'm happy to state I've finally won out over it." -- Elwood P. Dowd, Harvey
participants (3)
-
Dethe Elza -
Patrick K. O'Brien -
Phillip J. Eby