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
On 06/12/2018 20:00, Ted Mielczarek wrote:
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
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
