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

[Guido van Rossum]

[someone]
> >> 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.

[me]
> >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/).

[John Skaller]
>         So, it would be relatively easily to generate a standard
> python module?

Without more context I don't know what you mean by "generate a
standard Python module".  If you are asking whether it is easy to
compile a Python extension given just its source, yes: just copy
/usr/local/lib/python1.5/config/Makefile.pre.in in the directory where 
the extension lives, write a one-line Setup file containing the module 
name and the source file name, and execute these two shell commands:

  make -f Makefile.pre.in boot
  make

This assumes that "python" is on your $PATH.

> >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.

I know all that, but it requires building Python with CygWin.  Do you
realize that most Python users on Windows download the installer from
python.org?  That doesn't contain the C sources (they don't have a
C compiler so what good would it do them) and has a PYTHON15.DLL
created with VC++.  Oh well, I guess that if your software requires
them to have a compiler, you might as well require them to grab the
sources and rebuild Python -- but you must realize that this will put
off most potential users...

>         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.

*IF* they can produce compatible 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 :-))

I never said that.

--Guido van Rossum (home page: http://www.python.org/~guido/)