Re: [Distutils] Access to Python config info

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_.
I'm a 'platform independent' bigot ;-)
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.
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

John Skaller writes:
1) does the OS support symbolic or hard links?
import os hasattr(os, "link") hasattr(os, "symlink")
hasattr(os, "system")
6) What is the size of a Python 'integer' 'float'? 7) What is the eol character sequence?
I thought this was in there, but can't recall where.
# true for JPython sys.platform[:4] == "java"
For most of this, probably so. Recall also that Guido & others recommend "feature tests" to determine the availability of functionality rather than having a separate flag to indicate availability. There are many ways in which this is more reliable and maintainable, though what we're currently describing as sysconfig remains pertinant. I would expect sysconfig to be used mostly by things like distutils and not by typical programs. Hence, it would be good for os to not import it. -Fred -- Fred L. Drake, Jr. <fdrake@acm.org> Corporation for National Research Initiatives 1895 Preston White Dr. Reston, VA 20191

Quoth John Skaller, on 17 December 1998 [on whether the config module should be builtin or a separate .py file]:
There are a number of reasons why you don't want to do this, and it all boils down to the fact that in the C world you cannot reliably link two object files if one was compiled with compiler X and the other with compiler Y. A concrete example that has burned me in the past: the 'assert' macro supplied with certain versions of GCC uses a function that is only available when you use GCC to drive the link, ie. when you the GCC runtime library is linked in. I have been bitten by this in two widely separated areas: distributing a C library that was used by ImageMagick and GIMP; people had problems if they compiled ImageMagick or GIMP with the system compiler and my library with gcc. Likewise, I have seen problems with a C library/Perl extension that I wrote; if someone manages to build the library and extension with gcc and link against a Perl built with cc, they stumble across this problem. (Less likely, because the SOP in Perl-world is to build extensions the same way Perl itself was built -- for this very reason, no doubt!) Similarly, different C++ compilers might use different name-mangling algorithms, again causing symbol mismatches. Anyways, these all constitute reasons for *strong recommendations* against fiddling with the compiler or flags. I'll concede that someone who *really* knows what they're doing should be allowed to do this (but they should also have to sign a disclaimer first ;-). And if they want to edit a machine-generated Python library to make this change permanent, well, again the responsibility rests on their shoulders. Extension builders should certainly have the option to override defaults from the config module, eg. ./setup.py build --cc=gcc --optimize=-g or ./setup.py install --prefix=/home/greg or something like that. (Fodder for another thread, perhaps.) However, I can definitely buy Andrew's and Robin's arguments in favour of [config-module-name].py rather than building it into Python. Greg -- Greg Ward - software developer gward@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 x287 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913
participants (3)
-
Fred L. Drake
-
Greg Ward
-
John Skaller