On 1/2/2015 6:23 AM, Ehsan Akhgari wrote:
Note that MSVC 2012 is "supported" in the sense that we'd accept patches
that help fix it, and we won't check in patches that require compiler
features that 2012 does not support. Traditionally people who use
compilers different than what we use on our infra may face local build
issues from time to time, and this is not specific only to MSVC 2012.
What has become clear is that MVCV 2012 is NOT actually supported in the
second sense, but only in the first sense. That is, we do check in
patches that break VS 2012, and those patches are not backed out when
the breakage is discovered. The way to fix that is by adding automatic
builders that test for VS 2012 breakage. If that is not done, then
people should be strongly discouraged from using VS 2012 rather than
saying it is "supported".
The issue for me is that there were multiple patches required to support
VS2013 in the first place, and AFAIK these have not been ported to older
gecko versions. So I don't believe that you can compile esr31 with
VS2013.
Why is that an issue? When we discuss dropping support for compilers,
we only talk about mozilla-central, and you should be able to install
MSVC2012 and 2013 side by side and use the compiler you want depending
on what tree you are trying to build.
I would hope that you would be considering the larger question of what
is optimal for the developer community, and not simply what does not
break mozilla-central. Yes I suppose that developers can figure out how
to install multiple versions of VS on their computers, but that just
adds one more obstacle to developing with Mozilla. Isn't making it
easier to contribute supposed to be a goal?
But actually what will probably happen is that people will just install
VS 2013, and then when it comes to to check if their patch runs on esr31
they'll just not bother to recompile since it involves the onerous task
of adding support to their system for an older compiler. That would have
real quality ramifications. I know that what I'll do initially is just
upgrade to VS 2013 on my development machine now and hope that I am
sufficiently motivated to install VS2012 when it comes time to test
something on esr31.
But what benefit would we get out of doing that? Keeping MSVC2012
working should not be a goal to itself. I can't think of what benefit
adding official support for MSVC2012 can have.
If by adding "official" support you mean adding automatic tests, the
benefit is to actually make VS 2012 viable, which it is increasingly
becoming not viable. That is, you will actually do what you already
claim that you do, namely "we won't check in patches that require
compiler features that 2012 does not support"
But I can see that the support for this is weak. I don't think that
dropping VS 2012 support is correct obviously, but I am not going to
continue arguing for it. I suppose I'll just have to deal with the
additional complexity of supporting multiple VS versions. Add another
few percentage points to the already-too-high fraction of my time spent
just keeping things building instead of actually fixing bugs.
:rkent
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
