Dropping support for compiling with MSVC in the near future

[Ted Mielczarek]

Hello,

In light of the fact that we've switched to clang-cl for our Windows builds[1], we are planning to drop support for compiling Firefox with MSVC in the near future[2]. Our estimate is that this will happen sometime in Q1. Supporting more than one compiler is a maintenance burden and we've already seen developers spend considerable time getting their patches that work with clang-cl to build with MSVC. We are currently blocked by the fact that our aarch64-windows builds are still using MSVC and we are waiting on upstream clang-cl work to switch those builds to clang-cl. Once that takes place we no longer have a compelling reason to continue supporting MSVC.

To preempt the question--when this happens we intend to make MSVC error in configure, and not just move MSVC to Tier 3 "patches welcome" status. Our reasoning is that Tier 3 configurations still create work: developers spend time building in those configurations, and lack of CI coverage means that when they inevitably break they waste time trying to fix things. Bugs get filed, and other developers waste time trying to help or reviewing patches to fix things. Explicitly unsupporting MSVC is the best way for us to convey the fact that developers should not be using it and we will not accept patches to fix issues that only affect MSVC.

If you have specific reasons for continuing to use MSVC please let us know. If there are deficiencies in clang-cl compared to MSVC we should get them filed and fixed.

Thanks,
-Ted

1. https://bugzilla.mozilla.org/show_bug.cgi?id=1443590
2. https://bugzilla.mozilla.org/show_bug.cgi?id=1512504

[Kris Maglione]

\o/

Post by Ted Mielczarek
Hello,
In light of the fact that we've switched to clang-cl for our Windows builds[1], we are planning to drop support for compiling Firefox with MSVC in the near future[2]. Our estimate is that this will happen sometime in Q1. Supporting more than one compiler is a maintenance burden and we've already seen developers spend considerable time getting their patches that work with clang-cl to build with MSVC. We are currently blocked by the fact that our aarch64-windows builds are still using MSVC and we are waiting on upstream clang-cl work to switch those builds to clang-cl. Once that takes place we no longer have a compelling reason to continue supporting MSVC.
To preempt the question--when this happens we intend to make MSVC error in configure, and not just move MSVC to Tier 3 "patches welcome" status. Our reasoning is that Tier 3 configurations still create work: developers spend time building in those configurations, and lack of CI coverage means that when they inevitably break they waste time trying to fix things. Bugs get filed, and other developers waste time trying to help or reviewing patches to fix things. Explicitly unsupporting MSVC is the best way for us to convey the fact that developers should not be using it and we will not accept patches to fix issues that only affect MSVC.
If you have specific reasons for continuing to use MSVC please let us know. If there are deficiencies in clang-cl compared to MSVC we should get them filed and fixed.
Thanks,
-Ted

[Jonathan Kew]

Post by Ted Mielczarek
Hello,
In light of the fact that we've switched to clang-cl for our Windows builds[1], we are planning to drop support for compiling Firefox with MSVC in the near future[2]. Our estimate is that this will happen sometime in Q1. Supporting more than one compiler is a maintenance burden and we've already seen developers spend considerable time getting their patches that work with clang-cl to build with MSVC. We are currently blocked by the fact that our aarch64-windows builds are still using MSVC and we are waiting on upstream clang-cl work to switch those builds to clang-cl. Once that takes place we no longer have a compelling reason to continue supporting MSVC.

While I sympathize with the concern that "supporting more than one
compiler is a maintenance burden", this still leaves me feeling a little
uneasy. Ensuring that our code builds successfully with multiple
compilers is a useful way to keep us from becoming dependent on quirks
of a particular tool, and different compilers may provide different
(valid, useful) diagnostics that we should not simply ignore.

Our C/C++ code should (IMO) be standard and portable enough to build
with any modern, mainstream C++ compiler; writing code for a clang
monoculture feels wrong, a bit like building websites for a Blink
monoculture...

JK

Post by Ted Mielczarek
To preempt the question--when this happens we intend to make MSVC error in configure, and not just move MSVC to Tier 3 "patches welcome" status. Our reasoning is that Tier 3 configurations still create work: developers spend time building in those configurations, and lack of CI coverage means that when they inevitably break they waste time trying to fix things. Bugs get filed, and other developers waste time trying to help or reviewing patches to fix things. Explicitly unsupporting MSVC is the best way for us to convey the fact that developers should not be using it and we will not accept patches to fix issues that only affect MSVC.
If you have specific reasons for continuing to use MSVC please let us know. If there are deficiencies in clang-cl compared to MSVC we should get them filed and fixed.
Thanks,
-Ted
1. https://bugzilla.mozilla.org/show_bug.cgi?id=1443590
2. https://bugzilla.mozilla.org/show_bug.cgi?id=1512504
_______________________________________________
dev-platform mailing list
https://lists.mozilla.org/listinfo/dev-platform

[Kris Maglione]

Post by Jonathan Kew
While I sympathize with the concern that "supporting more than one
compiler is a maintenance burden", this still leaves me feeling a
little uneasy. Ensuring that our code builds successfully with
multiple compilers is a useful way to keep us from becoming dependent
on quirks of a particular tool, and different compilers may provide
different (valid, useful) diagnostics that we should not simply
ignore.
Our C/C++ code should (IMO) be standard and portable enough to build
with any modern, mainstream C++ compiler; writing code for a clang
monoculture feels wrong, a bit like building websites for a Blink
monoculture...

As it stands, we need to remain compatible with at least GCC and
Clang, because some of our static analysis code still depends on
GCC plugins. But supporting MSVC is a much larger burden. It
tends to be the slowest compiler to adopt major new features,
and the fact that it's closed source means that we're completely
dependent on Microsoft to fix bugs which are trivial for us to
fix in our open source tool chains.

I'm all for not chaining ourselves so tightly to Clang, though.

[Gijs Kruitbosch]

Can someone elaborate on what this means for debugging on Windows, and
for our onboarding story on Windows?

I don't do this very often, but I ran into this today and the story is
already very poor. I'm currently trying to work out why a patch I have
crashes on startup. I tried using google, and found
https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/Debugging_on_Windows,
which is hopelessly out of date (like, how old is MSVS6? Why does it
talk about "Mozilla" as the executable? etc.). After struggling and
eventually finding the correct path for devenv (the executable name for
MSVS), and using `./mach run --debugger=devenv`, it opens MSVS, clicking
"Start" in it runs Firefox, but it doesn't break on
exceptions/segfaults/whatever, and so it just stops running again
shortly afterwards, with cryptic console output indicating a non-0 exit
status. No crash stack, no minidump, nothing. This may well be a
coincidence and nothing to do with clang itself, but it seems worth
pointing out.

It also seems worth bearing in mind that despite the vast majority of
our users being on Windows, the developing experience on Windows is
basically horrible (when compared to Linux/Mac). We're already making
people install MSVS to get the relevant Windows SDKs (manually, not
supported via ./mach bootstrap, and hopefully ticking the right boxes in
the installer or they have to do it again until they do win at
checkbox-golfing), and now we're telling them that although we just made
them download multiple gigs of stuff and install a pile of MS C++
compiler infrastructure on their machine, we can't actually use that and
they need to download *another* C++ compiler to actually build/debug
Firefox? That seems pretty terrible in terms of getting/encouraging
contributions from people that don't work on Firefox fulltime.

~ Gijs

Post by Ted Mielczarek
Hello,
In light of the fact that we've switched to clang-cl for our Windows builds[1], we are planning to drop support for compiling Firefox with MSVC in the near future[2]. Our estimate is that this will happen sometime in Q1. Supporting more than one compiler is a maintenance burden and we've already seen developers spend considerable time getting their patches that work with clang-cl to build with MSVC. We are currently blocked by the fact that our aarch64-windows builds are still using MSVC and we are waiting on upstream clang-cl work to switch those builds to clang-cl. Once that takes place we no longer have a compelling reason to continue supporting MSVC.
To preempt the question--when this happens we intend to make MSVC error in configure, and not just move MSVC to Tier 3 "patches welcome" status. Our reasoning is that Tier 3 configurations still create work: developers spend time building in those configurations, and lack of CI coverage means that when they inevitably break they waste time trying to fix things. Bugs get filed, and other developers waste time trying to help or reviewing patches to fix things. Explicitly unsupporting MSVC is the best way for us to convey the fact that developers should not be using it and we will not accept patches to fix issues that only affect MSVC.
If you have specific reasons for continuing to use MSVC please let us know. If there are deficiencies in clang-cl compared to MSVC we should get them filed and fixed.
Thanks,
-Ted
1. https://bugzilla.mozilla.org/show_bug.cgi?id=1443590
2. https://bugzilla.mozilla.org/show_bug.cgi?id=1512504