[Distutils] Proposal: C/C++ compiler identification

[Greg Ward]

*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