[Distutils] Proposal: C/C++ compiler identification
Guido van Rossum
Tue, 15 Dec 1998 10:15:23 -0500
> >> 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
> 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
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/)