[Python-Dev] Backporting the 3.5+ Windows build project files to 2.7

Zachary Ware zachary.ware+pydev at gmail.com
Thu Jun 25 17:12:39 CEST 2015

On Thu, Jun 25, 2015 at 8:54 AM, M.-A. Lemburg <mal at egenix.com> wrote:
> On 22.06.2015 19:03, Zachary Ware wrote:
>> Using the backported project files to build 2.7 would require two
>> versions of Visual Studio to be installed; VS2010 (or newer) would be
>> required in addition to VS2008.  All Windows core developers should
>> already have VS2010 for Python 3.4 (and/or VS2015 for 3.5) and I
>> expect that anyone else who cares enough to still have VS2008 probably
>> has (or can easily get) one of the free editions of VS 2010 or newer,
>> so I don't consider this to be a major issue.
> To understand this correctly:
> In order to build Python 2.7.11 (or a later version), we'd
> now need VS 2008 *and* VS 2010 installed ?

Using the backported project files, yes, two versions of VS would be
required.  However, the second version doesn't have to be VS 2010, it
could be 2010, 2012, 2013, 2015, or any from the future (until
Microsoft changes the format of the project files again).

> This doesn't sound like it would make things easier for
> people who need to build their own Python on Windows, e.g.
> because they are freezing their apps for distribution, or
> using their own internal special builds.
> For VS 2008 we now have a long-term solution thanks to MS.
> The same is not true for VS 2010 (download links are not official
> anymore), so we'd complicate things again by requiring the
> mixed compiler setup.

For anyone building 2.7 and any other (current) version of Python on
the same machine, all the necessary pieces are already in place.

The main motivation for backporting is to make it easier to build
Python with ICC.  Pre-backport, Intel gave me a list of 9 steps they
were doing to build 2.7.10 with ICC.  Post-backport, it's just
`PCbuild\build.bat -e [-p x64] [-d] "/p:PlatformToolset=Intel C++
Compiler XE 15.0" "/p:BasePlatformToolset=v90"` (the bracketed options
being optional, for 64-bit and debug builds, respectively).

There are some benefits for MSVC builds too, though: it's easier to do
a parallel build, and OpenSSL and Tcl/Tk/Tix are built by the project
files, so the whole build can be done much quicker.  The new project
files for Tcl and Tk also take care of copying their DLLs into PCbuild
so that _tkinter can find them without having to mess around with
PATH.  My patch also fixes a couple of long-standing bugs with finding
the right libraries for 64-bit Tcl/Tk and the test suite undoing the
work of FixTk.py after any test that imports Tkinter, both of which
were exacerbated by the rest of the patch.

> If you keep the old VS 2008 build files around, I'd be
> fine with having an optional upgrade path to newer
> compilers :-)

The old files are moved to PC/VS9.0, and they work as expected as far
as I've tested them.  Btw, the upgrade path to newer compilers is just
a side-effect which I'm kind of torn about.  On one hand, making it
easier to build 2.7 with the "wrong" compiler is bound to lead to
issues somewhere somehow.  On the other hand, people are already doing
so anyway, with their own upgraded project files.

> It's rather unlikely that the project files will change much
> in coming years, so there shouldn't be much maintenance
> effort.

Hopefully not :)


More information about the Python-Dev mailing list