756108 - Stop support for building with Visual Studio 2005 (= VC8)

Status: RESOLVED DUPLICATE of bug 866425

(Firefox Build System :: General, defect)

Description

[Serge Gautherie (:sgautherie)]

http://support.microsoft.com/lifecycle/search/default.aspx?sort=PN&alpha=Visual+Studio+2005&Filter=FilterNO

"Visual Studio 2005 Professional Edition" and "Visual Studio 2005 Standard Edition" have
*General Availability Date   = 1/27/2006
*Mainstream Support End Date = 4/12/2011
*Extended Support End Date   = 4/12/2016

VC8 is now in its "Extended Support" period.

***

https://developer.mozilla.org/En/Developer_Guide/Build_Instructions/Windows_Prerequisites

Since Gecko 13, VC10 is used instead of VC8(sp1) for the official (Firefox) builds, though the latter is still supported.

But it looks like we are "starting" to hit issues to build newer code with VC8: see blocked bugs.

***

Though there seems to be (not too hard, code) workarounds for the time being,
Mozilla may consider dropping VC8 support in (near) future.

Comment 1

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Not only should we drop support for VC8, but we should drop support for VC9 too.

Especially after we upgrade our Mac compilers, if we dropped VC8 and VC9 support, we will have a lot of TR1/C++11 support available on all platforms. If we keep supporting VC9 then we will still have to keep re-inventing things that are already standard C++, like unique_ptr.

Previously, we always supported two versions of Visual Studio, but I think that was done because the compiler wasn't free. Now, there's no reason to support a version of Visual Studio older than what we're using on the buildbots.

Comment 2

[(not currently active) Ted Mielczarek]

I disagree. If we hit a compelling case then we can re-evaluate, but bumping compiler requirements adds extra burden on community members and other people working with Mozilla code.

Comment 3

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

TR1 and C++11 (even the subsets implemented in VS2010) are compelling enough.

Also, the extra burden is minimal; you download and install Visual Studio 2010 (Express C++) if you haven't already, you start running C:\mozilla-build\start-msvc10.bat instead of c:\mozilla-build\start-msvc9.bat, and you blow away your obj-dir. Before, there was more of a burden, because there was no free version of VS. Things are much better now.

For Windows, the only requirement for the benefit of "community members" is "must be buildable with the Visual Studio Express C++ edition" of whatever the required Visual Studio version is.

Comment 4

[(not currently active) Ted Mielczarek]

You can say that, but I'm still unconvinced.

Comment 5

[Serge Gautherie (:sgautherie)]

Ftr,
*One of the reason to file this bug was that Microsoft ended VC8 "Mainstream Support" more than a year ago.
 *I didn't check VC9.
*If VC8 support is retained, could there be a VC8 Build box added back, as Linux has a Bq box, fwiw?
 *Maybe the same for VC9?

Comment 6

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

(In reply to Ted Mielczarek [:ted] from comment #4)
> You can say that, but I'm still unconvinced.

fwiw, I agree with bsmith.

Comment 7

[(no longer active)]

(In reply to Kyle Huey [:khuey] ([e-mail]) from comment #6)
> (In reply to Ted Mielczarek [:ted] from comment #4)
> > You can say that, but I'm still unconvinced.
> 
> fwiw, I agree with bsmith.

Me too.  Ted, what is your criteria for what would make this worth it?

Comment 8

[(not currently active) Ted Mielczarek]

(In reply to Serge Gautherie (:sgautherie) from comment #5)
> *If VC8 support is retained, could there be a VC8 Build box added back, as
> Linux has a Bq box, fwiw?

No, I don't think that's necessary. We have lots of configurations that we like to keep working that we don't have build coverage for. I certainly wouldn't say that VC8 has to be Tier-1, meaning you have to back out immediately for bustage, but I think it's useful to keep it working.

Every tool requirement we have is a burden on developers. There are lots of volunteer contributors who don't have lots of time (or bandwidth), and forcing them to download a whole new toolchain when their existing one already works is a burden. There are plenty of companies using Mozilla code in their products, and they may not be using the latest and greatest toolchain. Forcing them to switch to a new toolchain means spending the time and money to upgrade.

Note that we've never (AFAIK) unsupported a GCC version in configure (although we probably should unsupport some ancient versions), despite GCC being even easier to upgrade.

That being said, I will leave you with two points:
1) I am not opposed to the current summary of this bug. VC2005 is a pretty old compiler, and it's two versions behind what we're using, and (the key point), we've actually hit issues with supporting it in code that's landing in m-c. If it causes developers to spend time on workarounds, then it might be worthwhile to instead drop support.

2) I haven't heard anyone talk about any C++11 features that they would love to use but are being held back because of supporting VC9. If there's an actual compelling case there of something we could use if only we dropped VC9 support then I'd like to hear it. I would suspect that this would tighten our compiler requirements on other platforms as well (see the point about GCC above). We've also been building out MFBT with polyfills for language features that we want to use but haven't been able to rely on wide compiler support for. Are the C++11 features we'd like to use implementable in this way?

Comment 9

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Ted Mielczarek [:ted] from comment #8)
> 2) I haven't heard anyone talk about any C++11 features that they would love
> to use but are being held back because of supporting VC9.

Generally, we do try to work within the existing limitations, in the interest of expediency. But, that doesn't mean that we are happy dealing with these limitations indefinitely and unnecessarily.

> If there's an
> actual compelling case there of something we could use if only we dropped
> VC9 support then I'd like to hear it. I would suspect that this would
> tighten our compiler requirements on other platforms as well (see the point
> about GCC above). 

nullptr, unique_ptr, tr1::bind, conditional<>, rvalue references (move constructors) are the ones that are most important to me, that are supported in VS2010.

One of the problems that affect me materially, and more than others working on Gecko: I would like to add better unit testing support to NSS using gtest. To make the tests easier to write, we need some something like unique_ptr so we can do:

    typedef unique_ptr<CERTCertificate, CERT_DestroyCertificate>
            ScopedCertificate;

We have similar capability already in mozilla-central with ScopedRef and nsAutoRef. But, we cannot rely on any parts of MFBT or XPCOM in NSS tests, because NSS must be buildable separately from the rest of the tree. So, without being able to rely on unique_ptr (which is VS2010+, GCC 4.4+), I would have to write or copy/paste another scoped reference implementation into the NSS tree.

> We've also been building out MFBT with polyfills for
> language features that we want to use but haven't been able to rely on wide
> compiler support for. Are the C++11 features we'd like to use implementable
> in this way?

In general, I would much prefer to update all our compiler requirements to adding new code to MFBT (or Gecko in general) as soon as those compiler upgrades can be done on the buildbots. The more standard C++ we use, the easier it is for developers--especially new developers--to be productive with the codebase.

Comment 10

[Jeff Walden [:Waldo]]

(In reply to Ted Mielczarek [:ted] from comment #8)
> 2) I haven't heard anyone talk about any C++11 features that they would love
> to use but are being held back because of supporting VC9.

There are still complaints about breaking gcc 4.1 (!) builds these days, occasionally.  And it looks like Apple loves itself some gcc 4.2 for at least another couple years.  Dropping VC8 and VC9 gives us <stdint.h>.  But with ancient gcc as a requirement I'm not sure you get too much C++11, at least not for use in cross-platform code.  If you want to change gcc requirements too, then you start getting real wins.  I'm guessing this is a bit much scope creep for this bug, tho, and I don't know if you get much when you consider 4.2 as the upper limit on requirement changes.

> Are the C++11 features we'd like to use implementable in this way?

I've been doing the polyfill thing partly because the stuff I saw could be done that way and partly because I assumed compiler requirements were essentially fixed, or at least I didn't care enough to argue it, fight a battle, etc.  Looking at the Wikipedia page, I don't think there are very many more polyfillable C++11 facets we might consider, if any.

Comment 11

[Jeff Walden [:Waldo]]

Although I should perhaps note that those gcc 4.0/4.1 complaints are from our own tinderboxen, because apparently l10n repack machines use the distro-provided compiler, not the compiler we actually use to compile stuff on those machines.  And there are some projects (not Firefox) that have tinderboxen with older compilers as well.  Great little snafu.  Again something I really didn't want to get into an argument about to get changed, especially with there being some touching on project politics.  Back to coding now!

Comment 12

[Justin Dolske [:Dolske]]

(In reply to Ted Mielczarek [:ted] from comment #8)

> Note that we've never (AFAIK) unsupported a GCC version in configure
> (although we probably should unsupport some ancient versions), despite GCC
> being even easier to upgrade.

Huh, I was just about to ask the opposite: Are there things that make it difficult for developers to upgrade their VS install? IME it's been a trivial download + install, whereas with gcc you've got to muck around toolchains and packages and all that.

Comment 13

[Gregory Szorc [:gps]]

I think the conversation about VC9 should move to a mailing list.

Comment 14

[Mike Hommey [:glandium]]

I'll add a few things about using more C++11:
- We're still using gcc 4.2 on mac, and until we switch to clang, we can't rely on C++11.
- OpenBSD is stuck on gcc 4.2, so relying on C++11 would make the OpenBSD folks (at least Landry Breuil) unhappy.
- Some gcc 4.4 headers are broken for C++11 support, and we disable C++11 support when we detect the situation (bug 654493). This fortunately doesn't affect android (for some reason ; probably the headers are different, there). But this affects desktop (for instance, this affects me when backporting current releases to Debian stable, which uses gcc 4.4), so relying on C++11 means depending on gcc 4.5+, not 4.4+.
- I, personnally, have been using VC8 because that's what we were using on the tinderboxes until very recently. I haven't spent the time to upgrade yet. I'd expect at least some people to be in the same situation I am.

Comment 15

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Brian Smith (:bsmith) from comment #3)
> For Windows, the only requirement for the benefit of "community members" is
> "must be buildable with the Visual Studio Express C++ edition" of whatever
> the required Visual Studio version is.

If we stick to this requirement, then VS2010 will likely be the last version of Visual Studio that we could ever require:

http://arstechnica.com/information-technology/2012/05/no-cost-desktop-software-development-is-dead-on-windows-8/

So, perhaps even the requirement of supporting a free compiler on every platform is (or will be soon) unreasonable.

Comment 16

[Rain [:rain1] (inactive)]

(In reply to Brian Smith (:bsmith) from comment #15)
> 
> If we stick to this requirement, then VS2010 will likely be the last version
> of Visual Studio that we could ever require:
> 
> http://arstechnica.com/information-technology/2012/05/no-cost-desktop-
> software-development-is-dead-on-windows-8/
> 
> So, perhaps even the requirement of supporting a free compiler on every
> platform is (or will be soon) unreasonable.

For anyone still keeping track, MS relented and now offers VC11 express for desktop. It remains to be seen whether they'll do the same for future versions.