[Distutils] Anonymous CVS up-and-running

[Greg Stein]

John Skaller wrote:
> 
> >  Agreed.  I seem to recall someone had sent patches to support C++,
> >possibly to the C++-SIG.  Does anyone know exactly what's needed?
> ...
> I have done this, it is about 5 minutes work for a makefile
> expert. It took me half a day to get working properly :-)

Until these patches are applied to the main distribution, then I think
we can safely ignore the issue.

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

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.

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

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.

> > > 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?

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/