Re: [Distutils] Anonymous CVS up-and-running

Agreed. I seem to recall someone had sent patches to support C++, possibly to the C++-SIG. Does anyone know exactly what's needed?
Yes, I know what is 'needed', but not how to get it. What is required is that the python executable be built using C, and another version of it built using C++. Let me call them python.exe and pythonpp.exe. For gcc/g++, three extra steps are required in the makefile: 1) compile python.c using C++ as well as C, name it pythonpp.o(bj). This is the _only_ file that has to be compiled with C++. 2) Link that main object file with the C built python library. The result, pythonpp.exe, works just like python.exe, _except_ that it will accept full C++ dynamic link libraries as python modules: that is, it will support RTTI, exception handling, and proper constructor initialisation of virtual tables, correctly. 3) Install pythonpp.exe as well as python.exe I have done this, it is about 5 minutes work for a makefile expert. It took me half a day to get working properly :-)
In my opinion, part of the solution is to factor the 'variables' more logically, and then modify the makefile to use that factorisation. To start with, may I suggest _private_ variables which are not really required for sysconfig, be renamed in the makefile to some convention, such as a leading underscore: these can be ignored by the sysconfig parser as implementation details. Anything with a pathname related to the build directory is likely to be private: for example the current 'CFLAGS' contains -I../../something which is clearly useless to the installed system. So I'd rename that variable _CFLAGS. Then I'd create a real CFLAGS which _only_ has the option flags, no include directories. This allows the flags to be combined with the include directory options obtained for the _installed_ system. (That information is available now in sysconfig -- and indeed directly from Python)
Huh? The code in the CVS archive is wrong (for my system). It creates a directory name using '/usr/local/lib/python1.5/' which is NOT where config.h is installed. It is installed in /usr/local/include/python1.5 I.e. 'lib' should read 'include'. As a result, the module fails on my system. It is a stock standard Linux installation, IMHO it has put config.h in the right place, therefore sysconfig.py is wrong. :-) (Sorry, it is hard for me to quote stuff because I email on NT, but do real work on Linux :-)
Thanks!
Neither do I. Factorisation doesn't complicate the interface, it simplifies it. There are two categories of information, and they come from separate sources. The data strucure should surely reflect this?
I think each source of data should be separate, including the makefile info and the autoconf info. The existing architecture is correct, IMHO: its the simplest possible 'pythonic' representation of the raw data. [This is not enough for the high level goal, but it seems correct to build this lower level first]
OK.
8) LINKCC = ' gcc' has a bad leading space.
Fixed in the patch.
Thanks.
Yes, I agree. It is clear that while the current set of attributes is not quite right, it contains a lot of information. Therefore, the first step of just getting it into a pythonic format is a good one. ------------------------------------------------------- John Skaller email: skaller@maxtal.com.au http://www.maxtal.com.au/~skaller phone: 61-2-96600850 snail: 10/1 Toxteth Rd, Glebe NSW 2037, Australia

John Skaller wrote:
Until these patches are applied to the main distribution, then I think we can safely ignore the issue.
I have a better idea: rather than all this work on the distribution itself, let's do a Version 1 that places *everything* into the sysconfig as it does now. USERS of the sysconfig can simply ignore most of it. That works, and that gets us to a solution faster. We need code to work with, more than we need the right code.
Quite true. On my RedHat 5.1 system, I have config.h in /usr/include/python1.5. Note that /usr/lib/python1.5/config *does* exist, but it just doesn't have the headers. Also, with a manual install of Python, it places it into /usr/local/include/python1.5.
Not really. Clients should just use what they want. We should get the information into Python and let the higher levels deal with it. sysconfig should be simple and flat. The less we structure it, the smaller chance of structuring it wrong (in terms of future needs). -g -- Greg Stein, http://www.lyra.org/

John Skaller writes:
I have done this, it is about 5 minutes work for a makefile expert. It took me half a day to get working properly :-)
Cool. Send Guido a patch and rationale as to why it should be in the standard distribution. Frankly, the reason to install pythonpp is lost on me.
No. What's in the Makefile is there for the Makefile's use. If we don't need part of it, it can be ignored. Many make variables have a long history, and should not be renamed. CFLAGS definately qualifies!
What's the variable/constant that has this wrong? I don't see "config.h" in the values.
The specific sources are, in this case, not indicative of useful categories.
I think each source of data should be separate, including the makefile info and the autoconf info.
The Makefile includes information generated by the configure script; that's a significant part of what configure does. *Parsing* the different source types can be intelligently separated; the usefulness of the separation is still open to debate. It doesn't hurt, and is done in the patch I sent earlier. -Fred -- Fred L. Drake, Jr. <fdrake@acm.org> Corporation for National Research Initiatives 1895 Preston White Dr. Reston, VA 20191

John Skaller wrote:
Until these patches are applied to the main distribution, then I think we can safely ignore the issue.
I have a better idea: rather than all this work on the distribution itself, let's do a Version 1 that places *everything* into the sysconfig as it does now. USERS of the sysconfig can simply ignore most of it. That works, and that gets us to a solution faster. We need code to work with, more than we need the right code.
Quite true. On my RedHat 5.1 system, I have config.h in /usr/include/python1.5. Note that /usr/lib/python1.5/config *does* exist, but it just doesn't have the headers. Also, with a manual install of Python, it places it into /usr/local/include/python1.5.
Not really. Clients should just use what they want. We should get the information into Python and let the higher levels deal with it. sysconfig should be simple and flat. The less we structure it, the smaller chance of structuring it wrong (in terms of future needs). -g -- Greg Stein, http://www.lyra.org/

John Skaller writes:
I have done this, it is about 5 minutes work for a makefile expert. It took me half a day to get working properly :-)
Cool. Send Guido a patch and rationale as to why it should be in the standard distribution. Frankly, the reason to install pythonpp is lost on me.
No. What's in the Makefile is there for the Makefile's use. If we don't need part of it, it can be ignored. Many make variables have a long history, and should not be renamed. CFLAGS definately qualifies!
What's the variable/constant that has this wrong? I don't see "config.h" in the values.
The specific sources are, in this case, not indicative of useful categories.
I think each source of data should be separate, including the makefile info and the autoconf info.
The Makefile includes information generated by the configure script; that's a significant part of what configure does. *Parsing* the different source types can be intelligently separated; the usefulness of the separation is still open to debate. It doesn't hurt, and is done in the patch I sent earlier. -Fred -- Fred L. Drake, Jr. <fdrake@acm.org> Corporation for National Research Initiatives 1895 Preston White Dr. Reston, VA 20191
participants (3)
-
Fred L. Drake
-
Greg Stein
-
John Skaller