Backporting the 3.5+ Windows build project files to 2.7
Hi,
As you may know, Steve Dower put significant effort into rewriting the project files used by the Windows build as part of moving to VC14 as the official compiler for Python 3.5. Compared to the project files for 3.4 (and older), the new project files are smaller, cleaner, simpler, more easily extensible, and in some cases quite a bit more correct.
I'd like to backport those new project files to 2.7, and Intel is willing to fund that work as part of making Python ICC compilable on all platforms they support since it makes building Python 2.7 with ICC much easier. I have no intention of changing the version of MSVC used for official 2.7 builds, it *will* remain at MSVC 9.0 (VS 2008) as determined the last time we had a thread about it. VS 2010 and newer can access older compilers (back to 2008) as a 'PlatformToolset' if they're installed, so all we have to do is set the PlatformToolset in the projects at 'v90'. Backporting the projects would make it easier to build 2.7 with a newer compiler, but that's already possible if somebody wants to put enough work into it, the default will be the old compiler, and we can emit big scary warnings if somebody does use a compiler other than v90.
With the stipulation that the officially supported compiler won't change, I want to make sure there's no major opposition to replacing the old project files in PCbuild. The old files would move to PC\VS9.0, so they'll still be available and usable if necessary.
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.
The backported files could be added alongside the old files in PCbuild, in a better-named 'NewPCbuild' directory, or in a subdirectory of PC. I would rather replace the old project files in PCbuild, though; I'd like for the backported files to be the recommended way to build, complete with support from PCbuild/build.bat which would make the new project files the default for the buildbots.
I have a work-in-progress branch with the backported files in PCbuild, which you can find at https://hg.python.org/sandbox/zware/log/project_files_backport. There are still a couple bugs to work out (and a couple unrelated changes to PC/pyconfig.h), but most everything works as expected.
Looking forward to hearing others' opinions,
Updating the build system to better handle changes in underlying platforms is one of the "standard exemptions" arising from Python 2.7's long term support status, so if this change makes things easier for contributors on Windows, +1 from me.
Cheers, Nick.
Zachary Ware wrote:
With the stipulation that the officially supported compiler won't change, I want to make sure there's no major opposition to replacing the old project files in PCbuild. The old files would move to PC\VS9.0, so they'll still be available and usable if necessary.
I'm selfishly -0, since this won't benefit me and will give me more work (I don't develop 2.7 other than to build the releases, so this will just cause me to mess with my build machine). But since other people are doing most of the work I'm not going to try and block it.
I don't see any real need to emit scary warnings about compiler compatibility - a simple warning like in 3.5 for old compilers is fine.
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.
It may have a workaround, but it also could be a serious blocking issue for those who can't install another version. Especially since there's no benefit to the resulting builds.
The backported files could be added alongside the old files in PCbuild, in a better-named 'NewPCbuild' directory, or in a subdirectory of PC. I would rather replace the old project files in PCbuild, though; I'd like for the backported files to be the recommended way to build, complete with support from PCbuild/build.bat which would make the new project files the default for the buildbots.
Agreed, just replace them. PCBuild is messy enough with the output files in there (I'd avoid moving them - plenty of the stdlib and test suite expects them to be there), we don't need duplicate project files.
Cheers, Steve
I have a work-in-progress branch with the backported files in PCbuild, which you can find at https://hg.python.org/sandbox/zware/log/project_files_backport. There are still a couple bugs to work out (and a couple unrelated changes to PC/pyconfig.h), but most everything works as expected.
Looking forward to hearing others' opinions,
Zach
I'd like to backport those new project files to 2.7,
Would this change anything about how extensions are built?
There is now the "ms compiler for 2.7" would that work? Or only in concert with VS2010 express?
-CHB
and Intel is willing to fund that work as part of making Python ICC compilable on all platforms they support since it makes building Python 2.7 with ICC much easier. I have no intention of changing the version of MSVC used for official 2.7 builds, it *will* remain at MSVC 9.0 (VS 2008) as determined the last time we had a thread about it. VS 2010 and newer can access older compilers (back to 2008) as a 'PlatformToolset' if they're installed, so all we have to do is set the PlatformToolset in the projects at 'v90'. Backporting the projects would make it easier to build 2.7 with a newer compiler, but that's already possible if somebody wants to put enough work into it, the default will be the old compiler, and we can emit big scary warnings if somebody does use a compiler other than v90.
With the stipulation that the officially supported compiler won't change, I want to make sure there's no major opposition to replacing the old project files in PCbuild. The old files would move to PC\VS9.0, so they'll still be available and usable if necessary.
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.
The backported files could be added alongside the old files in PCbuild, in a better-named 'NewPCbuild' directory, or in a subdirectory of PC. I would rather replace the old project files in PCbuild, though; I'd like for the backported files to be the recommended way to build, complete with support from PCbuild/build.bat which would make the new project files the default for the buildbots.
I have a work-in-progress branch with the backported files in PCbuild, which you can find at https://hg.python.org/sandbox/zware/log/project_files_backport. There are still a couple bugs to work out (and a couple unrelated changes to PC/pyconfig.h), but most everything works as expected.
Looking forward to hearing others' opinions,
Zach _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/chris.barker%40noaa.gov
On Mon, Jun 22, 2015 at 5:20 PM, Steve Dower Steve.Dower@microsoft.com wrote:
Zachary Ware wrote:
With the stipulation that the officially supported compiler won't change, I want to make sure there's no major opposition to replacing the old project files in PCbuild. The old files would move to PC\VS9.0, so they'll still be available and usable if necessary.
I'm selfishly -0, since this won't benefit me and will give me more work (I don't develop 2.7 other than to build the releases, so this will just cause me to mess with my build machine). But since other people are doing most of the work I'm not going to try and block it.
I will be making sure that the files in PC\VS9.0 do still work properly; I could also try to adjust paths in Tools\msi such that you would only need to use PC\VS9.0 instead of PCbuild. I have yet to successfully build an MSI for any Python release, though, so I can't make any promises about that working.
I don't see any real need to emit scary warnings about compiler compatibility - a simple warning like in 3.5 for old compilers is fine.
That's the one I was talking about, actually :). Describing it as a "big scary" warning was probably a bit much.
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.
It may have a workaround, but it also could be a serious blocking issue for those who can't install another version. Especially since there's no benefit to the resulting builds.
The easiest workaround would be to use the project files in PC\VS9.0. It might work to install only whatever gets you a new-enough MSBuild, but I haven't tested that at all and thus don't know. I will tell you that it works to build the backported pcbuild.proj with \Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe, invoked from a clean environment on a machine with VS 2008, 2010, 2013, and 2015RC installed, though.
The backported files could be added alongside the old files in PCbuild, in a better-named 'NewPCbuild' directory, or in a subdirectory of PC. I would rather replace the old project files in PCbuild, though; I'd like for the backported files to be the recommended way to build, complete with support from PCbuild/build.bat which would make the new project files the default for the buildbots.
Agreed, just replace them. PCBuild is messy enough with the output files in there (I'd avoid moving them - plenty of the stdlib and test suite expects them to be there), we don't need duplicate project files.
That probably explains a few of the failures I'm still seeing that I hadn't dug into yet.
On Mon, Jun 22, 2015 at 6:29 PM, Chris Barker - NOAA Federal chris.barker@noaa.gov wrote:
I'd like to backport those new project files to 2.7,
Would this change anything about how extensions are built?
There is now the "ms compiler for 2.7" would that work? Or only in concert with VS2010 express?
It should have absolutely no impact on building extensions. If it does, that's a bug to be fixed. Regular users of Python on Windows (those who don't build their own) should have no idea that anything has changed at all.
-- Zach
On 23 June 2015 at 11:45, Zachary Ware zachary.ware+pydev@gmail.com wrote:
On Mon, Jun 22, 2015 at 6:29 PM, Chris Barker - NOAA Federal chris.barker@noaa.gov wrote:
I'd like to backport those new project files to 2.7,
Would this change anything about how extensions are built?
There is now the "ms compiler for 2.7" would that work? Or only in concert with VS2010 express?
It should have absolutely no impact on building extensions. If it does, that's a bug to be fixed. Regular users of Python on Windows (those who don't build their own) should have no idea that anything has changed at all.
I'd suggest explicitly reaching out to the Stackless folks to get their feedback. As I believe the switched to a newer compiler and VC runtime for Windows a while back, I suspect it will make their lives easier rather than harder, but it's still worth asking for their input.
Regards, Nick.
On Mon, Jun 22, 2015 at 10:37 PM, Nick Coghlan ncoghlan@gmail.com wrote:
I'd suggest explicitly reaching out to the Stackless folks to get their feedback. As I believe the switched to a newer compiler and VC runtime for Windows a while back, I suspect it will make their lives easier rather than harder, but it's still worth asking for their input.
From a glance at the stackless repo, it looks like it still uses
VS2008's project files (which pretty much means using MSVC 9), but I could have easily missed something.
Christian, what say you? Would having the project files from 3.5 backported to 2.7 (but still using MSVC 9) be positive, negative, or indifferent for Stackless?
On 22/06/2015 18:03, Zachary Ware wrote:
As you may know, Steve Dower put significant effort into rewriting the project files used by the Windows build as part of moving to VC14 as the official compiler for Python 3.5. Compared to the project files for 3.4 (and older), the new project files are smaller, cleaner, simpler, more easily extensible, and in some cases quite a bit more correct.
I'd like to backport those new project files to 2.7, and Intel is willing to fund that work as part of making Python ICC compilable on all platforms they support since it makes building Python 2.7 with ICC much easier.
Very much +1. Anything which eases building on Windows is good. I'd meant a while ago to put in a vote of thanks to you & Steve for the incremental improvements and tidy-ups to the build area, and I'd certainly like to see this proposed change go in.
I'll try to find time to check out your branch and build from there, but unless you've done anything bizarre I'm sure I'll be happy with it.
TJG
Hi Zack,
On 23.06.15 06:42, Zachary Ware wrote:
On Mon, Jun 22, 2015 at 10:37 PM, Nick Coghlan ncoghlan@gmail.com wrote:
I'd suggest explicitly reaching out to the Stackless folks to get their feedback. As I believe the switched to a newer compiler and VC runtime for Windows a while back, I suspect it will make their lives easier rather than harder, but it's still worth asking for their input.
From a glance at the stackless repo, it looks like it still uses VS2008's project files (which pretty much means using MSVC 9), but I could have easily missed something.
Christian, what say you? Would having the project files from 3.5 backported to 2.7 (but still using MSVC 9) be positive, negative, or indifferent for Stackless?
I am very positive about your efforts.
We wanted to create a Stackless 2.8 version end of 2013 with support for newer compilers, to begin with. After a while, we stopped this, and I left the branch in a private, unmaintained repository. https://bitbucket.org/stackless-dev/stackless-private/branch/2.8-slp
Maybe you can make use of this, use it as you like it. You will get an invitation.
cheers - Chris
On Jun 23, 2015, at 06:27, Christian Tismer tismer@stackless.com wrote:
On 23.06.15 06:42, Zachary Ware wrote:
Christian, what say you? Would having the project files from 3.5 backported to 2.7 (but still using MSVC 9) be positive, negative, or indifferent for Stackless?
I am very positive about your efforts.
We wanted to create a Stackless 2.8 version end of 2013 with support for newer compilers, to begin with. After a while, we stopped this, and I left the branch in a private, unmaintained repository. https://bitbucket.org/stackless-dev/stackless-private/branch/2.8-slp
Thanks, Chris!
Since there has been no violent opposition (and some positive support), I’ve cleaned up the patch and posted it:
https://bugs.python.org/issue24508
Reviews (and review-by-testing) welcome!
On 22.06.2015 19:03, Zachary Ware wrote:
Hi,
As you may know, Steve Dower put significant effort into rewriting the project files used by the Windows build as part of moving to VC14 as the official compiler for Python 3.5. Compared to the project files for 3.4 (and older), the new project files are smaller, cleaner, simpler, more easily extensible, and in some cases quite a bit more correct.
I'd like to backport those new project files to 2.7, and Intel is willing to fund that work as part of making Python ICC compilable on all platforms they support since it makes building Python 2.7 with ICC much easier. I have no intention of changing the version of MSVC used for official 2.7 builds, it *will* remain at MSVC 9.0 (VS 2008) as determined the last time we had a thread about it. VS 2010 and newer can access older compilers (back to 2008) as a 'PlatformToolset' if they're installed, so all we have to do is set the PlatformToolset in the projects at 'v90'. Backporting the projects would make it easier to build 2.7 with a newer compiler, but that's already possible if somebody wants to put enough work into it, the default will be the old compiler, and we can emit big scary warnings if somebody does use a compiler other than v90.
With the stipulation that the officially supported compiler won't change, I want to make sure there's no major opposition to replacing the old project files in PCbuild. The old files would move to PC\VS9.0, so they'll still be available and usable if necessary.
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 ?
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.
The backported files could be added alongside the old files in PCbuild, in a better-named 'NewPCbuild' directory, or in a subdirectory of PC. I would rather replace the old project files in PCbuild, though; I'd like for the backported files to be the recommended way to build, complete with support from PCbuild/build.bat which would make the new project files the default for the buildbots.
If you keep the old VS 2008 build files around, I'd be fine with having an optional upgrade path to newer compilers :-)
It's rather unlikely that the project files will change much in coming years, so there shouldn't be much maintenance effort.
I have a work-in-progress branch with the backported files in PCbuild, which you can find at https://hg.python.org/sandbox/zware/log/project_files_backport. There are still a couple bugs to work out (and a couple unrelated changes to PC/pyconfig.h), but most everything works as expected.
Looking forward to hearing others' opinions,
On Thu, Jun 25, 2015 at 8:54 AM, M.-A. Lemburg mal@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 :)
M.-A. Lemburg wrote:
For VS 2008 we now have a long-term solution thanks to MS.
Without the change to the project files, the compiler at http://aka.ms/vcpython27 isn't sufficient to build Python itself. In theory, with even more patching to the projects (or otherwise making up for the fact that the linked compiler doesn't include the platform toolset files so that MSBuild can find/use it), we may be able to make Python 2.7 buildable with that compiler and any version of MSBuild. Currently we have to build via pcbuild.sln, which requires a full Visual Studio 2008 installation (or Express for C++).
This also makes it more viable to use the Windows SDK compilers. If you install the Windows SDK 7.0 (which includes MSVC9) and Windows SDK 7.1 (which includes the platform toolset files for MSVC9 - toolsets were invented later than the 7.0 release) then you should be able to build from the command line or any version of Visual Studio from 2010 onwards.
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.
VS 2010 Express editions are still linked at the bottom of https://www.visualstudio.com/en-us/products/visual-studio-express-vs.aspx, though they appear to be protected behind a Microsoft account login (apparently so we can offer you the latest/greatest tools you have access to and not just the link you followed). Visual Studio 2013 Express for Desktop should also work (I'll be testing that as soon as I get a chance).
Cheers, Steve
On 25.06.2015 17:12, Zachary Ware wrote:
On Thu, Jun 25, 2015 at 8:54 AM, M.-A. Lemburg mal@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).
Sounds good.
BTW: I remember there was some discussion a while ago to get ICC licenses to core devs. Has there been any progress on this ?
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.
So it's still possible to build with "just" VS 2008 installed or will the VS 2010 (or later) be required for those old files as well ?
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.
I guess will have the discussion about switching compilers for Python 2.7 again at some point. People writing extensions will sooner or later want to use features from more recent compilers for Python 2.7 as well :-)
It's rather unlikely that the project files will change much in coming years, so there shouldn't be much maintenance effort.
Hopefully not :)
On Thu, Jun 25, 2015 at 1:48 PM, M.-A. Lemburg mal@egenix.com wrote:
On 25.06.2015 17:12, Zachary Ware wrote:
The old files are moved to PC/VS9.0, and they work as expected as far as I've tested them.
So it's still possible to build with "just" VS 2008 installed or will the VS 2010 (or later) be required for those old files as well ?
Only VS 2008 is required for the old files. Building in PC/VS9.0/ post-backport is exactly the same as building in PCbuild/ pre-backport.
I guess will have the discussion about switching compilers for Python 2.7 again at some point. People writing extensions will sooner or later want to use features from more recent compilers for Python 2.7 as well :-)
I expect the same outcome every time it comes up --- too much breakage for not enough benefit :)
On Thu, Jun 25, 2015 at 10:42 AM, Steve Dower Steve.Dower@microsoft.com wrote:
This also makes it more viable to use the Windows SDK compilers. If you install the Windows SDK 7.0 (which includes MSVC9) and Windows SDK 7.1 (which includes the platform toolset files for MSVC9 - toolsets were invented later than the 7.0 release) then you should be able to build from the command line or any version of Visual Studio from 2010 onwards.
I suspected this, but hadn't brought it up because I hadn't looked into it in depth. This sounds good though! The SDKs are supported quite a bit longer than VS versions, aren't they?
Zachary Ware wrote:
On Thu, Jun 25, 2015 at 10:42 AM, Steve Dower Steve.Dower@microsoft.com wrote:
This also makes it more viable to use the Windows SDK compilers. If you install the Windows SDK 7.0 (which includes MSVC9) and Windows SDK 7.1 (which includes the platform toolset files for MSVC9 - toolsets were invented later than the 7.0 release) then you should be able to build from the command line or any version of Visual Studio from 2010 onwards.
I suspected this, but hadn't brought it up because I hadn't looked into it in depth. This sounds good though! The SDKs are supported quite a bit longer than VS versions, aren't they?
The downloads are available for longer than VS, but they are also unsupported. They also have known installation issues that won't be fixed, so they aren't really a *good* option, just a possibility.
Cheers, Steve
participants (7)
-
Chris Barker - NOAA Federal -
Christian Tismer -
M.-A. Lemburg -
Nick Coghlan -
Steve Dower -
Tim Golden -
Zachary Ware