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, 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:

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.



dev-platform mailing list

Reply via email to