I think we need to separate out being able to build for the pc-windows-gnu
target vs. using the entire msys2/mingw64 environment.
We need to continue to be able to build for pc-windows-gnu because the
debugging story with rust+msvc is still not great. We have the beginnings of
local variables etc. with the llvm update, but there's still type information
that needs a lot of work. With the gnu target, gdb, along with all the python
rust helpers work. (Even more fun: we'll want to have msys2 as a better
supported firefox build target so that we can debug things with gdb there too!)
We *should* be able to make everything work using the native windows python,
and only that. mach can make sure that's the one it uses to create its
virtualenv. That removes the python issue. For gcc version, we could (and
probably should) just switch to clang -- or specify an exact package version
that are known good. The dependencies are the same as on other platforms --
openssl, etc.
So, I don't think we should kill it off any time soon, but we should switch the
default to MSVC and limit the amount of msys2 dependencies we have.. but we
should still be able to build.
- Vlad
On Thursday, September 8, 2016 at 11:08:17 AM UTC-4, Lars Bergstrom wrote:
> Now that Vlad has landed the amazing support for compiling with Visual
> C++ instead of the mingw gcc toolchain, I'd like to propose that we
> remove mingw from our automation, documentation, and support. There
> are a few reasons:
> 1) Python is a total crazy mess. Users get messed up with the three
> (3) different pythons installed, and we even have to ask them to
> globally rename one of them.
> 2) Tracking mingw versions is pretty rough. The recent gcc update ICEs
> in spidermonkey. They keep adding / removing / changing their launch
> shortcuts, bitrotting our documentation.
> 3) Packaging. Figuring out which set of curiously-licenesed DLLs we
> need to package up in our Windows installer is a challenge (much
> easier in the MSVC case b/c we can merge in the usual MSM or point at
> a different MSI & check for the installed product).
>
> That said, I know that there are a few benefits on the mingw side:
> 1) Better gcc.
> 2) Contributors to the build / automation stuff can "fake it until
> they make it" and hope that the macOS/Linux scripts they write just
> happen to work on Windows in mingw.
> 3) Somebody might have a real mingw {something} that wants to include
> Servo bits, and if we aren't testing mingw, it will almost definitely
> break in the future.
>
> Do people have opinions one way or another on this? I'm not dead-set
> on removing it, and could definitely be convinced to just switch the
> default to MSVC and hide the mingw documentation but keep testing it
> if there are compelling reasons to do so.
> - Lars
_______________________________________________
dev-servo mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-servo
