[Python-Dev] MinGW And The other Py2.4 issue
"Martin v. Löwis"
martin at v.loewis.de
Sat Dec 18 23:34:11 CET 2004
Paul Moore wrote:
> OK, I've got a copy of the Python sources, and had a look. The change
> needed to msi.py to include libpythonXX.a in the installer looks
> simple. But I'm less sure as to where to build the file. It seems to
> me that msi.py is not the right place - that's focused on building the
> installer, not building the files to be installed.
Don't worry about this: there is already quite some building going on
in msi.py. If you look at the CVS copy of Tools/msi, you find that
it now has a nmake makefile to build msisupport.dll, which replaces
the VB scripts. It also extracts msvcr71.dll from the merge module
(.msm) each time it is invoked. So having yet another build process
would be just fine; adding it to the makefile would have the added
advantage that nmake will compare time stamps for us (if it is easier
to do in Python than in nmake, that would be a reason not to use
> On the other hand, including it in the build process is a nuisance, as
> well, as it would add a dependency on mingw (or cygwin) to the MSVC
> build process.
That is definitely undesirable. Lots of people build Python using the
project files, and only few need the packaging to work.
> My feeling is that building libpythonXX.a should be a separate step,
> handled by a dedicated script, which gets run before msi.py.
Making it separate is fine, as long as msi.py invokes/calls it.
> What do others (particularly Martin) think? Should I keep the steps
> separate, and focused on one task each, or should I incorporate the
> build of libpythonXX.a into msi.py, so that the installer build still
> requires just one step?
Having the entire process involve as few manual steps as possible is
definitely an important goal. Keeping it modular (in terms of splitting
it into several files) is also a good idea, and one which does not
conflict at all with the "fully automatic" goal.
msi.py supports a config.py which allows to add customization. Putting
cygwin_dir = r"C:\cygwin"
into msi.py might be appropriate, with an option to set cygwin_dir to
None, to indicate that cygwin should not be used in the build process.
(similar to the way have_tcl already works).
More information about the Python-Dev