On 2015-01-02 1:31 PM, Kent James wrote:
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.
Yes, exactly my point.
> 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".
Yes, people should be discouraged from using MSVC2012 locally. Please
note that:
a) It is impractical for Mozilla to test every single toolchain that
every single developer out there uses. If you want any kind of
guarantee that your builds will keep working, you should use MSVC2013 on
trunk and MSVC2010 on older versions than 37.
b) MSVC2012 has *never* been a supported compiler in the second sense,
and we have never used it on our infra (except for a short while for
testing unofficial Win64 builds, and I believe that is no longer the case.)
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?
Developers should use MSVC2013 locally. And that is true no matter
whether we decide to keep or drop support for MSVC2012.
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.
Testing whether or not something works on esr31 is best done on the try
server. Or, if that's something that you do very often, you need to
install and use MSVC2010 for it. MSVC2012 is not the answer.
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"
To be perfectly clear, I am very strongly opposed for us to spend any
money or time to run and test MSVC2012 builds on our infra, even if we
choose to keep support for it. We just cannot test every single build
configuration out there, and yours is not the only one that differs from
what we test on the infra.
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.
To me, the default answer to whether we should keep supporting MSVC2012
is "no", merely because it will require time and effort that will not
directly benefit our users as we do not use that compiler to release
Firefox. That is, without someone coming up with a good reason
otherwise, we should drop it. And not having it locally installed is
not a good reason. :-)
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
