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

Wed Apr 12 17:38:11 UTC 2017

Dylan, Nirbheek,

Thanks for the info.

I made a bit more progress.

One newbie question: what's your workflow to update a wrap patch?  Can we prototype changes locally without tarballing the patch?

One request: would it be possible to update the compiler args for both c and c++ with a single statement? (Maybe accept a list of languages instead of a single language?)

Jose

________________________________
From: Dylan Baker <dylan at pnwbakers.com>
Sent: Tuesday, April 11, 2017 2:04:20 AM
To: Jose Fonseca; Nirbheek Chauhan
Cc: mesa-dev at lists.freedesktop.org
Subject: Re: [Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)

Quoting Dylan Baker (2017-04-10 11:50:36)
> Quoting Nirbheek Chauhan (2017-04-10 06:59:02)
> > 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
>
> Jose,
>
> I installed meson from git as Nirbheek suggested, and it got the mingw build
> working, and fixed the appveyor build to actually start, although I ran into
> some problems with freeglut I'm not sure if I'll have time to fix today
> (although I'd like to get them fixed). If you pull my branch both the travis
> build will turn completely green, and the MinGW build turns green on appveyor,
> though MSVC still doesn't. My meson branch is based on yours and you should be
> able to apply the changes cleanly.

I have freeglut building, but we're waiting for a patch to land in meson for
getting vs_modules_defs to take generated files (which we need for either glew
or freeglut, I can't remember which off the top of my head) (and nirbheek was so
kind as to review). Assuming that my patch lands today you may be able to get
started on msvc for mesa-demos itself, or we may need to to a little more work
to get freeglut and/or glew building on msvc.

You'll probably want to either pull my meson branch, or at least look at to get
these fixes. without the updated freeglut patch meson will fail to build when it
fails the sha256 check.

Thank you for setting up appveyor support, btw. In lieu of a real windows
install with visual studio it's been very helpful, but I've never figured out
how to configure it for C/C++ projects.

Here's the patch for reference: https://github.com/mesonbuild/meson/pull/1606

Dylan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170412/1a6d0328/attachment.html>