1455375 - Discussion around building Firefox on MSYS2

Status: RESOLVED DUPLICATE of bug 1725895

(Firefox Build System :: General, defect, P5)

Description

[Ray Donnelly]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36

Steps to reproduce:

It seems that the efforts to swap the ageing and slow MSYS (make -j cannot work for example) with the modern MSYS2 have been cancelled in favour of WSL.

While I like WSL for some small tasks like testing Linux software on Windows I do not see its performance ever achieving anything close to native.

I would like to know where the *specific* issues were in MSYS2 that caused this change.

MSYS2 took measures to improve the interop. wrinkles beyond what MSYS provided, by, for example adding `MSYS2_ARG_CONV_EXCL` and `MSYS2_ENV_CONV_EXCL` to inhibit problematic path conversion and https://github.com/Alexpux/MINGW-packages contains a wealth of package build scripts that can be used as reference to work around any remaining issues. The distro itself is testament to the fact that you can build many open source projects that were not designed with Windows in mind easily on MSYS2.

So I'd like to know if there's things we can improve or advice we can offer to aid in achieving this goal.

Comment 1

[Nathan Froyd [:froydnj]]

gps probably has the most context here.

Comment 2

[Gregory Szorc [:gps]]

We could probably make MSYS2 work. If WSL didn't exist, we'd probably be moving to MSYS2. However, we felt that it would be less pain overall to make WSL - effectively a native Linux environment - work than MSYS2 - effectively Linux emulation on Windows. When we were experimenting with MSYS2, we ran into all kinds of problems with applications detecting they were running on Windows - but not really - and getting confused by the hybrid environment. This long tail of issues creates a substantial maintenance burden for us. WSL, however, mostly "just works" because for all intents and purposes it is a Linux environment. We would rather support N-1 build platforms because it is less work for us. And once we move away from MSVC and are using Clang for cross-compiling Windows builds from Linux, WSL effectively becomes the same as Windows.

Regarding performance, my experience has been that WSL performs *better* than Windows - including MSYS2 - at process creation. The Firefox build system creates thousands of processes and this adds up to several seconds during a build. However, I/O can be poor under both Windows and WSL (thanks NTFS).

Comment 3

[Mitchell Hentges [:mhentges] 🦀]

A couple notes here:

• WSL[2] has its own concerns, namely that we don't get to support N-1 platforms - sure, the build gets to do that, but then we're passing complexity onto Mach commands, who now need to manage the WSL<->Windows boundary, which is a problem for running Firefox, running tests, etc. Additionally, there's potential issues around IDE performance and iterating on Windows-specific work.
• We're doing the shorter migration here in the near future from MSYS to MSYS2, see this bug. So, we'll be doing what's recommended in the initial report 👍
• Thanks Ray for your good work and contributions over the years, you'll be missed :(