Gah! My plan is foiled - great point, though. So, I'll amend with this
*new* plan:
1) Continue building and running unit tests on the mingw build
2) Add a msvc builder
3) Update the documentation and default MSI build to use the results
of the msvc build
4) Begin investigation of an additional builder that uses the msvc
path, but sets clang-cl
5) Find ways to beg, borrow, or steal resources (or just revive my
knowledge from my old VS employment) to get better debugging on the
Rust msvc path so that we can remove #1. This will be super important
for gecko Windows devs, too, as you pointed out.
On Thu, Sep 8, 2016 at 4:39 PM, Vladimir Vukicevic <vladi...@mozilla.com> wrote:
> 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
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
