build: Add Windows MSYS2 build support & build guide #35421

This PR shall add MSYS2 build environment support using UCRT64 GNU toolchains ( including cmake and ninja ).

It is already specified that MSYS2 build "might work" on doc/build-windows.md however in order to build some patch with ./depends and ./cmake scripts was inevitable due to difference with Windows and Unix's file path, and it shall add MSYS_STAGING=1 env to tell those scripts to parse native windows file path correctly and thus it is possible to build bitcoin repo cloned on somewhere like C:\Users\UserName\Desktop\bitcoin , etc.

doc/build-windows-msys2.md is for the guide of how to do it, including building nsis installer and zip archives that would be produced with guix build.

The document guide added is very hacky ( since I am not a native english speaker ), so I would ask any maintainer or anyone patching it with friendly english guide as well.

<!--e57a25ab6845829454e8d69fc972939a-->

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

<!--006a51241073e994b41acfe9ec718e94-->

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/35421.

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

See the guideline for information on the review process. A summary of reviews will appear here.

<!--5faf32d7da4f0f540f40219e4f7537a3-->

this seems very hacky and niche. is this more or less popular than wsl?

why would we want to support this?

Hello @willcl-ark, WSL is still VM based build, and MSYS2 runs on native-like environment with native Windows path support which means you don't need to move around to VM to debug and edit source code on both locations.

And yeah MSYS2 is far from niche, it is built in with Github Actions on windows-latest env, and it should be able to support any GCC compile jobs while WSL would stall on some jobs ( yes, WSL is still buggy with my experience )

The bottleneck for this project is pull request review. This seems to be the first PR for introducing support for this toolchain, which indicates that there is little active demand for it. People interested in building Bitcoin Core natively on windows use msvc. Given this I don't think this will receive the review required in order to be merged soon. The change also includes build system changes that should probably be tested by CI in order to catch regressions. Due to these costs and apparent low demand, I don't think we should add support for this.

which indicates that there is little active demand for it @sedited Good point because even if it comes with msvc or wsl only a little people would be using it since you would be already using Unix not Windows in order to compile this project ( cause every toolchain including msvc, mingw-w64, MSYS2, or even WSL have active issues )

in order to catch regressions

There is a reason that this patch to fix windows file paths to something that gcc or cmake to understand are gated with MSYS_STAGING env is to avoid such issues, and I think it is safe code as it is gated already.

If we want, we could add another workflow to test MSYS2 builds on windows-latest env but I think we wouldn't need it, as this patch would only touch very minimal changes with depends scripts or nsis scripts which isn't very core scripts to bitcoin,

This patch is still for convenience to use open-source toolchains like MSYS2 or GCC instead of using MS's MSVC. From time to time there would be limitations where MSVC wouldn't support every C++ code that GCC supports ( which happens with some popular libraries like libmdbx ), so I think this is long term good goal to achieve.

From time to time there would be limitations where MSVC wouldn't support every C++ code that GCC supports ( which happens with some popular libraries like libmdbx ), so I think this is long term good goal to achieve.

There is CI which checks that MSVC can compile the Bitcoin Core C++ code, so I don't think what you describe is possible.

With that in mind, I don't understand why we need, what you yourself describe as the third "option which may work but is not extensively tested.

I don't see the point here.

And yeah MSYS2 is far from niche, it is built in with Github Actions on windows-latest env, and it should be able to support any GCC compile jobs while WSL would stall on some jobs ( yes, WSL is still buggy with my experience )

Can you share exact steps to reproduce? Some hand-wavy "bug" that a single person saw is not enough reason to add a whole new toolchain and way to build. Instead, we should just fix the WSL bug you are seeing.

@maflcko The bug with WSL is not related with Bitcoin though, actually it is more with the instability with the WSL environment itself.

With that in mind, I don't understand why we need, what you yourself describe as the third "option which may work but is not extensively tested.

And that I am not adding a third option "which may work but it is not extensively tested.", WSL was an other option for a long time with known bugs and instability while cross-compiling from linux was the only main option for windows.

This PR shall add a fully working windows-native build option that would work with open source toolings, not such closed sourced solutions like MSVC or WSL.

Also that this is the only solution to avoid recloning the whole repo on unix-like path ( $HOME dir ) but to build on windows path like Users/Username/Desktop directly. So I would recommend for a productive build setup for devs using windows.

~0. Not really convinced by this addition. If anything, I think a third Windows options that (partially) already exists is the Clang cross build.

Based on the feedback here, I don't think this pull request will attract sufficient review in a timely manner, so I'm closing this pull request again. @quadcpu if you are interested in using a non-msvc toolchain on windows, maybe take a look at #31507 in the meantime.