
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