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

John Skaller skaller@maxtal.com.au
Tue, 15 Dec 1998 10:55:05 +1000


At 10:27 13/12/98 -0500, Guido van Rossum wrote:
>> 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.
>
>Note that (for Unix at least) all this info is already being gathered
>by the configure script, and stored in the various Makefile.  The info
>also ends up being installed (look in
>/usr/local/lib/python1.5/config/).

        So, it would be relatively easily to generate a standard
python module?

>For Windows, since the only supported compiler is VC++, it could be
>hardcoded.  However, there's a very serious problem on Windows with
>Interscript's approach of invoking the compiler at run-time: most
>users don't have this compiler.  

        I wouldn't have call that a serious problem with the
approach. It is a difficulty :-)

        The current implementation doesn't handle failure
gracefully. But, after all, it is just python script: more work 
needs to be done to fetch or use pre-built binaries, 
and to detect _whether_ a compiler is available. Etc.

>I realize that gcc is available for
>free, but I think it isn't compatible with VC++.  As far as I know,
>VC++ is required if you want to use any of Mark Hammond's stuff (COM
>and MFC).  I don't know if Tcl/Tk can be used (without recompilation)
>from a gcc-based app, and I don't know how easy it would be to
>recompile.  (Does gcc on Windows have support for Win32 APIs at all?)

        To the best of my knowledge, CygWin will allow a Python
build on Windows: it supplies bash, ecgs version of C/C++,
and some other utilities. It also supplies Tcl/Tk/Tix. And it
allows standard Windows API calls as well.

        The advantage of the Interscript approach for Windows
users is that SOME of them do have a C/C++ compiler. So instead
of just ONE person supporting Windows, everyone with a compiler
would be able to build and contribute binaries.

        In other words, I can't see how the interscript approach
makes anything _worse_ for Windows users. I do agree the current
mechanism is inadequate! Hopefully, people can suggest ways
to improve the mechanism.

        Note also: JPython works on Windows! So Mark Hammonds
isn't the only build of Python that works on Windows :-))
-------------------------------------------------------
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