At 16:33 15/12/98 -0500, Greg Ward wrote:

Quoth John Skaller, on 16 December 1998:

...

I want the build process to put that information into a standard module. So I can get it out, and call up the compiler to make a C extension FROM PYTHON.

A-ha! Thank you -- now it comes clear. If I were more weasely, I could squirm out of it by saying "Well, this just follows from the requirement to easily build extension modules from source" or, "That's not a requirement, it's an implementation detail".

You could, you'd be right in both cases, and you cannot be expected to do everything: which is why I wrote the article. :-)

But I'm not a weasel,

You're not god. You started this list to get help from others.

and I think at some point I meant to mention this in the requirements document. So I've added it.

Great! Thanks!

I'm managing to keep implementation details out of the requirements list, though. In particular, my proposal is for a new 'sys.config' module which would contain everything you might need to know about how Python was configured.

YES!!!! I agree!

The most important items are the compiler, compiler flags, platform, and library installation directories.

Can I recommend you look at the interscript compilers module again? Instead of storing compiler flags, etc, you need an actual command that does the compilation. I.e. a python function that builds a command string and os.system's it. I don't think that 'data' can store this information, there are too many options. (Store the data as well!)

For an example of the degree of flaming overkill possible in this sort of module, try this

perl -MConfig -e 'map { print "$_: $Config{$_}\n" } sort keys %Config;'

You'll note that Perl's Config module stores *every* piece of information, gleaned, gathered, or queried from the user while running Perl's 'Configure' script. I don't think Python's sys.config need be *quite* so exhaustive,

I agree. After all, we can upgrade it later. The important thing is to get the module into the distribution. That way people can try it, and we'll find out what is missing. Anyone on this list have a Next machine??

Here's a very rough start (loosely based on my long experience with building Perl and my very brief experience with building Python, and a bit of poking through Python's makefiles):

This is too Unixy.

cc C compiler used to build Python cppflags C preprocessor flags used to build Python (-I, -D, -U) optimize optimization/debugging flags used to build Python ccsharedflags C compiler flags required to build shared objects extra_ccflags any other C compiler flags used to build Python ccflags all compiler flags used to build Python: cppflags + optimize + extra_ccflags ccextflags all compiler flags used to build Python extensions: cppflags + optimize + ccsharedflags + extra_ccflags

ldlibdirs -L flags used to build Python ldlibs -l flags used to build Python extra_ldflags any other needed linker flags ldsharedflags linker flags required to build shared objects ldflags all linker flags used to build Python: ldlibdirs + ldlibs + extra_ldflags ldextflags linker flags used to build Python extensions: ldlibdirs + ldlibs + ldsharedflags + extra_ldflags

I do not think _any_ of these flags, etc, are required individually. Nor do I see how they can possibly be enough. You are making assumptions about how an arbitrary compiler is invoked. What you need is a _function_ which compiles a c file for a shared library, and another which links them. In other words, you just need a string with some 'slots' in it for the filenames, and which has all the flags already set in the right places. The function is a generalisation of that. Have a look at the compilers module I posted here.

platform hardware/os/vendor (or something along those lines)

Yes. Something like that. This is necessarily crude information.

install_bindir directory to install binary executables install_scriptdir directory to install non-binary executables install_includedir directory to install C header files install_confincludedir directory to install platform- and build-specific C header files install_libdir main Python library directory install_sitelibdir directory for site-specific modules

Each of these things is what i call an 'install point'. It isn't clear that the list is enough: clients may want to organise things differently for different modules. For example, the place PYTHON puts scripts is definitely NOT where I want extension packages: I want them in the site-packages directory. This is tough. I think your list is a good start. Please add: install_htmldir directory to put HTML doco install_mandir directory for man pages (does anyone provide them?)

Obviously this is very sketchy.

An excellent sketch though. Why? because it is concrete enough to be argued about! ------------------------------------------------------- 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