[Distutils] Access to Python config info

[John Skaller]

>I'm torn on this one.  Building into Python prevents version skew,
>keeping it separate means it's easily readable without writing code.
>Both are compelling arguments.  Greg has given one voice in favour of a
>separate .py file... anyone else?

        I don't see any real choice: it has to be separate AND editable.
Because if I download a binary Windows version, the information will be wrong
for my system. The Unix version might be wrong too: perhaps I built
Python with gcc, but I want to build extensions with ecgs, or with edg.

        BTW: I see no harm in putting all the configuration
options into a dictionary as Marc Andre suggests. But I don't
think that is _enough_.

>Finally, John Skaller respond to my sketch of what should be in the
>config module:
>>         This is too Unixy.
>
>Absolutely true.  I never claimed to be anything but a Unix bigot.  

        I'm a 'platform independent' bigot ;-)

>Two rebuttals though:
>
>  * if platform X supports running the compiler from a command line or 
>    a script, surely that compiler can take some arguments... and surely
>    some of those arguments will deal with optimization/debugging, some
>    will deal with preprocessor settings, and some are just plain
>    miscellaneous

        Yes, but just having a bunch of flags doesn't tell me
how to invoke the compiler. For example, Unix compilers
use a -l flag, followed by the name of a library _without_
the first three letters (lib) and _without_ an extension,
and _without_ a pathname. Windows compilers don't use this
convention. You have to supply a full pathname, and some
of them do not support any kind of library search.

        For example, some compilers will compile a .c file as c.
And a .obj will get linked but not compiled. I'd need to know.
Is there a space allowed after the -o option?? Do I put the
name of the executable there, or the name _without_ .exe,
which is added automatically?

        Now, you could add meta-flags to answer these questions.
And it would become very complex to calculate how to
invoke the compiler.

>  * splitting the flags up into all those categories can be useful, but
>    it could be that I'm confusing the Python build process with the
>    extension module build process.  Perhaps the way to build an
>    extension should be carved in stone when Python itself is built, and 
>    extension builders shouldn't be allowed to muck with it.  If so,
>    then John is absolutely right about just calling a function to
>    invoke the compiler for such-and-such a situation.
>
>Gee, I guess that second one wasn't much of a rebuttal.  So much for my
>combative spirit. ;-)

        Do both! I don't see the 'function' as 'carved in stone',
i see it as the default easy way to do it.

        It will _not_ always be enough! But it should
always work for ISO compliant 'pure C', i.e. stuff that doesn't
call non-standard libraries (other than Python of course :-)
For example, it is enough for mxTools. Not enough for _tkinter.

-----------------------

Here are a questions that sys.config could answer:

        1) does the OS support symbolic or hard links?
        2) what information is in fstat?
        3) does the OS supply big/little endian Unicode files?
        4) What operating system is it? [This is a hard question]
        5) is os.system available?
        6) What is the size of a Python 'integer' 'float'?
        7) What is the eol character sequence?
        8) is there a 'drive' prefix?
        9) Can you delete an open file (Yes under Unix, No under NT)
        10) Is there a stderr and/or stdlog file
        11) Is there a console at all?
        12) Is there a compiler available?
        13) Is this J or C Python?

It may be the proper place for the answer is not in sys.config,
but in os. But the os module can compute the answers from
sys.config.


Hmm. Something I'm trying to say is that the point of the
module has to be to provide a _standard_ interface to 
various features such as compiler invocation and installation.
That is, a platform independent one (where possible of course).

Note that as soon as you consider JPython, the system compiler
is a java compiler, not a C compiler. 
-------------------------------------------------------
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