*This is not a flame* Please do not interpret it as such! Quoth John Skaller, on 13 December 1998:

This proposal is intended as a detail of the general requrements document for distutils.

The proposal is for the Python build process to create run time accessible identification data whose purpose is to facilitate run time building of

a) dynamically loadable binary python module objects *.so, .dll etc) b) external (shell) application tools (.exe etc)

This proposal does not fix the format of the information.

I have a couple of comments/questions on this -- mostly relating to the fact that I don't understand what you're talking about. First, when you talk about a "requirements document" for distutils, I can't help but be reminded that I've already written such a thing, posted it to the web, and asked for comments on this list. The only comments I got were a reminder to mention cross-platform friendliness and to add a blurb on dependency checking. That is, everyone on the list seemed pretty happy with the my proposed requirements document and just corrected a few lapses on my part. So, first question: are you proposing to throw out my requirements document and replace it with this? Or are you suggesting additions/modifications to mine? Next, you speak of the "Python build process" creating "run time accessible identification data". The first phrase gives me the impression that you're talking about building Python itself (and its library), which really isn't the province of the distutils suite. (If this SIG produces usable code soon enough, Guido might find it useful to rework how the standard library is built for Python 1.6. That's the only connection I see between the two.) I have no idea what you mean by "run time accessible identification data". Or rather, I can think of a half-dozen things you might mean. Please explain, or rephrase in a more conventional way.

--- I would like to consider a class instance, with one instance for each supported compiler/kind combination.

I recommend the Python make process attempt to provide access to C, C++, and Java compilers.

A binary build, such as Mark Hammonds Windows build, cannot be pre-configured for the client's system.

Note that interscript contains modules which compile C/C++ code. At present, the modules have to rewritten by the client (unless they're running RedHat Linux :-)

It is not clear to me if an _executable_ representation of the above requirement is appropriate. If not, at least the information required to create one should be made available.

The representation must be editable by the client somehow.

Now I'm really confused. The above statements are a mix of requirements/suggestions (providing access to C, C++, and Java compilers), design proposals (one class instance per supported compiler/kind combination), and random comments on existing systems (Mark Hammond's Windows build, your Interscript). John, *please* try to have your say in an organized fashion, using terms familiar to the whole audience. Remember, we're *not* all on the same wavelength -- I can't shake the impression that you're talking about something entirely different from the proposal we fleshed out at the Developer's Day session. Not having been there, obviously, places you at a bit of a disadvantage, but the summary I posted, along with the requirements and proposed interface, should give anyone a good flavour of what was decided in that session. If you have constructive comments or suggestions, we're open to them. If you want to tear the whole edifice down and replace it with a gleaming tower of ivory perfection, then you'll have to be a lot more coherent. (Please, *not* more voluminous: more *coherent*.) Again, *this is not a flame*, it is a plea for cogent and lucid exposition. 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