Re: [Distutils] Proposal: C/C++ compiler identification
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
[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/)
participants (2)
-
Guido van Rossum -
John Skaller