It seems a number of people are interested that the Python trunk switches to Visual Studio 2010 *now*. I've been hesitant to agree to such a change, as I still hope that Python can skip over VS 2010 (a.k.a. VS 10), and go straight to VS 11. However, I just learned that VS 11 supposed ready VS 10 project files just fine, with no need of conversion. So I'd be willing to agree to converting the Python trunk now. It will surely cause all kinds of issues, as any switching of Visual Studio releases has caused in the past. Since a number of people have already started with such a project, I'd like to ask for a volunteer who will lead this project. You get the honor to commit the changes, and you will be in charge if something breaks, hopefully finding out solutions in a timely manner (not necessarily implementing the solutions yourself). Any volunteers? Regards, Martin P.S. Here is my personal list of requirements and non-requirements: - must continue to live in PCbuild, and must replace the VS 9 project files "for good" - may or may not support automatic conversion to VS 9. If it turns out that conversion to old project files is not feasible, we could either decide to maintain old project files manually (in PC/VS9), or just give up on maintaining build support for old VS releases. - must generate binaries that run on Windows XP - must support x86 and AMD64 builds - must support debug and no-debug builds - must support PGO builds - must support buildbot - must support building all extensions that we currently build - may break existing buildbot installations until they upgrade to a new VS release - must support PCbuild/rt.bat - should support Tools/msi. If it doesn't, I'll look into it. - must nearly pass the test suite (i.e. number of additional failures due to VS 2010 should be "small")
On Tue, Jan 17, 2012 at 14:43, "Martin v. Löwis" <martin@v.loewis.de> wrote:
It seems a number of people are interested that the Python trunk switches to Visual Studio 2010 *now*. I've been hesitant to agree to such a change, as I still hope that Python can skip over VS 2010 (a.k.a. VS 10), and go straight to VS 11.
However, I just learned that VS 11 supposed ready VS 10 project files just fine, with no need of conversion.
So I'd be willing to agree to converting the Python trunk now. It will surely cause all kinds of issues, as any switching of Visual Studio releases has caused in the past.
Since a number of people have already started with such a project, I'd like to ask for a volunteer who will lead this project. You get the honor to commit the changes, and you will be in charge if something breaks, hopefully finding out solutions in a timely manner (not necessarily implementing the solutions yourself).
Any volunteers?
I previously completed the port at my old company (but could not release it), and I have a good bit of it completed for us at http://hg.python.org/sandbox/vs2010port/. That repo is a little bit behind 'default' but updating it shouldn't pose any problems.
I previously completed the port at my old company (but could not release it), and I have a good bit of it completed for us at http://hg.python.org/sandbox/vs2010port/. That repo is a little bit behind 'default' but updating it shouldn't pose any problems.
So: do you agree that we switch? Do you volunteer to drive the change? Regards, Martin
On Tue, Jan 17, 2012 at 15:01, "Martin v. Löwis" <martin@v.loewis.de> wrote:
I previously completed the port at my old company (but could not release it), and I have a good bit of it completed for us at http://hg.python.org/sandbox/vs2010port/. That repo is a little bit behind 'default' but updating it shouldn't pose any problems.
So: do you agree that we switch? Do you volunteer to drive the change?
I do, and I'll volunteer.
On Tue, Jan 17, 2012 at 15:11, Brian Curtin <brian@python.org> wrote:
On Tue, Jan 17, 2012 at 15:01, "Martin v. Löwis" <martin@v.loewis.de> wrote:
I previously completed the port at my old company (but could not release it), and I have a good bit of it completed for us at http://hg.python.org/sandbox/vs2010port/. That repo is a little bit behind 'default' but updating it shouldn't pose any problems.
So: do you agree that we switch? Do you volunteer to drive the change?
I do, and I'll volunteer.
Is this considered a new feature that has to be in by the first beta? I'm hoping to have it completed much sooner than that so we can get mileage on it, but is there a cutoff for changing the compiler?
Is this considered a new feature that has to be in by the first beta? I'm hoping to have it completed much sooner than that so we can get mileage on it, but is there a cutoff for changing the compiler?
At some point, I'll start doing this myself if it hasn't been done by then, and I would certainly want the build process adjusted (with all buildbots updated) before beta 1. Regards, Martin
On Thu, Jan 26, 2012 at 12:54:31PM -0800, martin@v.loewis.de wrote:
Is this considered a new feature that has to be in by the first beta? I'm hoping to have it completed much sooner than that so we can get mileage on it, but is there a cutoff for changing the compiler?
At some point, I'll start doing this myself if it hasn't been done by then, and I would certainly want the build process adjusted (with all buildbots updated) before beta 1.
I... I think I might have already done this, inadvertently. I needed an x64 VS2010 debug build of Subversion/APR*/Python a few weeks ago -- forgetting the fact that we're still on VS2008. By the time I got to building Python, I'd already coerced everything else to use VS2010, so I just bit the bullet and coerced Python to use it too, including updating all the buildbot scripts and relevant externals to use VS2010, too. Things that immediately come to mind as potentially being useful: * Three new buildbot scripts: - build-amd64-vs10.bat - clean-amd64-vs10.bat - external-amd64-vs10.bat * Updates to externals/(tcl|tk)-8.5.9.x so that they both build with VS2010. This was a tad fiddly. I ended up creating makefile.vs10 from win/makefile.vc and encapsulating the changes there, then calling that from the buildbot *-vs10.bat scripts. I had to change win/rules.vc, too. * A few other things I can't remember off the top of my head. So, I guess my question is, is that work useful? Based on Martin's original list, it seems to check a few boxes. Brian, what are your plans? Are you going to continue working in hg.python.org/sandbox/vs2010port then merge everything over when ready? I have some time available to work on this for the next three weeks or so and would like to help out. Regards, Trent.
I... I think I might have already done this, inadvertently. I needed an x64 VS2010 debug build of Subversion/APR*/Python a few weeks ago -- forgetting the fact that we're still on VS2008.
There is a lot of duplication of work going on here: at least four people have done the same. The more people duplicate the work, the more urgent it apparently becomes that the trunk switches "officially".
* Three new buildbot scripts: - build-amd64-vs10.bat - clean-amd64-vs10.bat - external-amd64-vs10.bat
When we switch, these should actually replace the current ones, rather than being additions.
So, I guess my question is, is that work useful?
Perhaps not, given that several other copies of that to draw from may exist. OTOH, I haven't heard anybody reporting these specific changes. In any case, it's now in Brian's hand. Regards, Martin
On Sun, Jan 29, 2012 at 14:23, Trent Nelson <trent@snakebite.org> wrote:
Brian, what are your plans? Are you going to continue working in hg.python.org/sandbox/vs2010port then merge everything over when ready? I have some time available to work on this for the next three weeks or so and would like to help out.
Yep, I'm working out of that repo, and any help you can provide would be great. I need to go back over Martin's checklist to find out what I've actually done in terms of moving old stuff around and whatnot, but the basic gist is that it builds and passes most of the test suite save for 5-6 modules IIRC.
On Sun, Jan 29, 2012 at 12:23:14PM -0800, Trent Nelson wrote:
* Updates to externals/(tcl|tk)-8.5.9.x so that they both build with VS2010.
Before I go updating tcl/tk, any thoughts on bumping our support to the latest revision, 8.5.11? I guess the same question applies to all the externals, actually (zlib, openssl, sqlite, bsddb, etc). In the past we've typically bumped up our support to the latest version prior to beta, then stuck with that for the release's life, right? Semi-related note: is svn.python.org/externals still the primary repo for externals? (I can't see a similarly named hg repo.) Trent.
On Tue, Jan 17, 2012 at 9:43 PM, "Martin v. Löwis" <martin@v.loewis.de> wrote: ...
P.S. Here is my personal list of requirements and non-requirements: ... - must generate binaries that run on Windows XP
I recently read about Firefox switching to VS2010 and therefore needing to drop support for Windows 2000, XP RTM (no service pack) and XP SP1. Indeed, [1] confirms that the VS2010 runtime (it's not clear if the C one, the C++ one or both) needs XP SP2 or higher. Just thought I'd share this so that an informed decision can be made, in my opinion it would be ok for Python 3.3 to drop everything prior to XP SP2. Maybe not very relevant, but [2] has some mention of statistics for Firefox usage on systems prior to XP SP2. [1] http://connect.microsoft.com/VisualStudio/feedback/details/526821/executable... [2] http://weblogs.mozillazine.org/asa/archives/2012/01/end_of_firefox_win2k.htm...
On Wed, Feb 1, 2012 at 15:37, Catalin Iacob <iacobcatalin@gmail.com> wrote:
On Tue, Jan 17, 2012 at 9:43 PM, "Martin v. Löwis" <martin@v.loewis.de> wrote: ...
P.S. Here is my personal list of requirements and non-requirements: ... - must generate binaries that run on Windows XP
I recently read about Firefox switching to VS2010 and therefore needing to drop support for Windows 2000, XP RTM (no service pack) and XP SP1. Indeed, [1] confirms that the VS2010 runtime (it's not clear if the C one, the C++ one or both) needs XP SP2 or higher.
Just thought I'd share this so that an informed decision can be made, in my opinion it would be ok for Python 3.3 to drop everything prior to XP SP2.
Maybe not very relevant, but [2] has some mention of statistics for Firefox usage on systems prior to XP SP2.
[1] http://connect.microsoft.com/VisualStudio/feedback/details/526821/executable... [2] http://weblogs.mozillazine.org/asa/archives/2012/01/end_of_firefox_win2k.htm...
We already started moving forward with dropping Windows 2000 prior to this coming up. http://mail.python.org/pipermail/python-dev/2011-May/111159.html was the discussion (which links an older discussion) and PEP-11 (http://www.python.org/dev/peps/pep-0011/) was updated accordingly.
On Wed, Feb 1, 2012 at 15:41, Brian Curtin <brian@python.org> wrote:
On Wed, Feb 1, 2012 at 15:37, Catalin Iacob <iacobcatalin@gmail.com> wrote:
On Tue, Jan 17, 2012 at 9:43 PM, "Martin v. Löwis" <martin@v.loewis.de> wrote: ...
P.S. Here is my personal list of requirements and non-requirements: ... - must generate binaries that run on Windows XP
I recently read about Firefox switching to VS2010 and therefore needing to drop support for Windows 2000, XP RTM (no service pack) and XP SP1. Indeed, [1] confirms that the VS2010 runtime (it's not clear if the C one, the C++ one or both) needs XP SP2 or higher.
Just thought I'd share this so that an informed decision can be made, in my opinion it would be ok for Python 3.3 to drop everything prior to XP SP2.
Maybe not very relevant, but [2] has some mention of statistics for Firefox usage on systems prior to XP SP2.
[1] http://connect.microsoft.com/VisualStudio/feedback/details/526821/executable... [2] http://weblogs.mozillazine.org/asa/archives/2012/01/end_of_firefox_win2k.htm...
We already started moving forward with dropping Windows 2000 prior to this coming up. http://mail.python.org/pipermail/python-dev/2011-May/111159.html was the discussion (which links an older discussion) and PEP-11 (http://www.python.org/dev/peps/pep-0011/) was updated accordingly.
Sorry, hit send too soon... Anyway, I can't imagine many of our users (and their users) are still using pre-SP2. It was released in 2004 and was superseded by SP3 and two entire OS releases. I don't know of a reliable way of figuring out whether or not pre-SP2 is a measurable demographic for us, but I can't imagine it's enough to make us hold up the move for another ~2 years.
participants (5)
-
"Martin v. Löwis" -
Brian Curtin -
Catalin Iacob -
martin＠v.loewis.de
-
Trent Nelson