[Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)

[Nirbheek Chauhan]

Hello Jose,

On Mon, Apr 10, 2017 at 5:41 PM, Jose Fonseca <jfonseca at vmware.com> wrote:
> I've been trying to get native mingw to build.  (It's still important to
> prototype mesademos with MSVC to ensure meson is up to the task, but long
> term, I think I'll push for dropping MSVC support from mesademos and piglit,
> since MinGW is fine for this sort of samples/tests programs.)
>
> However native MinGW fails poorly:
>
> [78/1058] Static linking library src/util/libutil.a
> FAILED: src/util/libutil.a
> cmd /c del /f /s /q src/util/libutil.a && ar @src/util/libutil.a.rsp
> Invalid switch - "util".
>
> So the problem here is that meson is passing `/` separator to the cmd.exe
> del command, instead of `\`.
>
> Full log
> https://ci.appveyor.com/project/jrfonseca/mesademos/build/job/6rpen94u7yq3q69n
>

This was a regression with 0.39, and is already fixed in git master:
https://github.com/mesonbuild/meson/pull/1527

It will be in the next release, which is scheduled for April 22. In
the meantime, please test with git master.

>
> TBH, this is basic windows functionality, and if it can't get it right then
> it shakes my belief that's it's getting proper windows testing...
>

I'm sorry to hear that.

>
> I think part of the problem is that per
> https://github.com/mesonbuild/meson/blob/master/.appveyor.yml Meson is only
> being tested with MSYS (which provides a full-blow POSIX environment on
> Windows), and not with plain MinGW.
>

Actually, this slipped through the cracks (I broke it!) because we
didn't have our CI testing MinGW. Now we do, specifically to catch
this sort of stuff: https://github.com/mesonbuild/meson/pull/1346.

All our pull requests are required to pass all CI before they can be
merged, and every bug fixed and feature added is required to have a
new test case for it, so I expect the situation will not regress
again.

Our CI is fairly comprehensive -- MSVC 2010, 2015, 2017, MinGW, Cygwin
on just Windows and getting better every day. The biggest hole in it
right now is BSD, and we would be extremely grateful if someone could
help us with that too!

> IMHO, MSYS is a hack to get packages that use autotools to build with MinGW.
> Packages that use Windows aware build systems (like Meson is trying to be)
> should stay as _far_ as possible from MSYS....
>

Yes, I agree. MSYS2 in particular is especially broken (the toolchain
is buggy and even the python3 shipped with it is crap) and we do not
recommend using it at all (although a surprisingly large number of
people use its toolchain, so we do support it). If you look closely,
we do not use MSYS itself, only MinGW:

https://github.com/mesonbuild/meson/blob/master/.appveyor.yml#L61

The MSYS paths are C:\msys64\usr\bin and the MinGW (toolchain) paths
are C:\msys64\mingw??\bin.

And in any case our codepaths for building something with the Ninja
backend on MSVC and MinGW are almost identical, and our MSVC CI does
not have any POSIX binaries in their path.

I even have all of Glib + dependencies building out of the box with
just Meson git + MSVC [https://github.com/centricular/glib/], and my
next step is to have all of GStreamer building that way.

Hope this clarifies things!

Cheers,
Nirbheek