Hello Jose, On Mon, Apr 10, 2017 at 5:41 PM, Jose Fonseca <jfons...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
