[Distutils] Anonymous CVS up-and-running

[John Skaller]

>  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 :-)   

> > 2) Some of the data, such as CFLAGS, is useless because it reflects
> > the python source build tree. On my system 
>
>  Misc/Makefile.pre.in manages to get things right in practice; some
>time needs to go into figuring out just how it does things and get
>sysconfig to do the right thing as well.  

        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)

> > 3) The directory for config.h is WRONG!
> > config.h lives in
>
>  What definition are you looking at?

        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 :-)

> > 4) On my system:
> > 
> >         SIZEOF_INT = '4'
>
>  Patch attached which gets this right in a general fashion.

        Thanks!

> > 5) I think the module should NOT just put values
> > into itself like
>
>  I don't see any need to complicate the interface.

        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?

> > 6) There is no information from Setup. It would be useful to
> > get the Tcl/Tk library and headers into the configuration
> > if it was built. Hmmm. :(
>
>  Variables defined in Setup & friends are included.  Otherwise,
>nothing from Setup is included.  This can be changed.  It may make
>sense to use a separate module for this (modconfig?).

        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]

> > 7) _init_posix should NOT modify a dictionary, but return one:
> > CHANGE:
>
>  This item is tightly related to item 5; let's deal with that one as
>the real issue.  The rest will fall out of that result.

        OK.

> > 8) LINKCC = ' gcc' has a bad leading space.
>
>  Fixed in the patch.

        Thanks.

> > 9) I have no idea how to use the available information.
> > There are flags all over the place.
>
>  Yes, that's what configure produces.  The next layer needs to put
>this information together in a usable form.  Reading the Makefile
>should help a lot in determining how the various bits should be put
>together.

        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