Dev-folk, I spoke with David Ascher over at ActiveState to explain our crossroads, and ask which tracks they expect to follow over the near future (while it's interesting or relevant to httpd 2.2, until httpd X is released.) He just confirmed I can share this summary from his Perl, Python and Tcl teams, hopefully there are some interesting nuggets here which we might take some cues from...
David Ascher wrote:
Bill, others. Here's the summary, and some details: Perl, Tcl: VC++ 6.0 for 32 bit for the foreseeable future Python 2.3: VC 6.0, Python 2.4 and later, VS2003 for the foreseeable future Details on Perl: We plan to continue to use VC++ 6.0 for 32 bit ActivePerl on Windows for the future. The disadvantages of the newer compilers are that they use a different runtime library for each release (msvcr70.dll for VS.NET, msvcr71.dll for VS2003 and msvcr80.dll for VS2005). Unlike msvcrt.dll used by VC++ 6.0 these libraries are not part of the OS and are not guaranteed to be on a given Windows machine, so they will have to be distributed with the application. This puts an additional burden on software bundling mechanisms like PerlApp, Perl2Exe and PAR. All modules in PPM module repositories need to continue to link against msvcrt.dll. Otherwise you couldn't install them into existing ActivePerl installations that may not have msvcrXX.dll installed. Or each module distribution would have to bundle the runtime library. Installing a module linked against msvcrXX.dll into an older ActivePerl will result in the loading of multiple C runtimes in one process. This can be a problem when any code in this process uses structured exception handling. For VS2005 you also have to provide an application manifest in order to load msvcr80.dll from the same directory, which is an additional hassle. I'm not sure yet if this would really be a problem or not. Our current setup with VC++ linking against msvcrt.dll works quite well. Starting with ActivePerl 815 we also seamlessly support using GCC (via MinGW) when VC++ 6.0 is not available on the PATH. This happens automatically with no additional configuration required. The GCC compilation still links against msvcrt.dll, so we still only use a single runtime library. MinGW is available for free, so we already do offer people a free alternative to VC++ to compile their own modules. Details on Tcl: Same as Perl. Details on Python: Python 2.3 (and hence ActivePython 2.3) builds with VC6. The current version, Python 2.4 (and hence ActivePython 2.4), builds with VS2003 (VC7.1). As Jan indicated, this means that ActivePython needs to distribute msvcr71.dll -- and it does (along with a couple other DLLs for full usability of some of the PyWin32 libraries). Discussion on python-dev indicates that python.org's Python builds will continue to use VS2003 (i.e. not switch to VS2005) for the next release of Python at least (Python 2.5). Maintaining binary compatibility with python.org's Python is important for ActivePython to ensure compatibility of all the 3rd party libraries out there. The current mod_python Windows binaries seem to be built with VS2003 as well: http://www.apache.org/dist/httpd/modpython/win/
