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

Fri Sep 22 19:14:19 UTC 2017

Quoting Jose Fonseca (2017-09-22 11:58:17)
> On 22/09/17 19:38, Dylan Baker wrote:
> > Quoting Jose Fonseca (2017-09-22 11:10:34)
> >> On 22/09/17 18:47, Nirbheek Chauhan wrote:
> >>> On Fri, Sep 22, 2017 at 10:19 PM, Jose Fonseca <jfonseca at vmware.com> wrote:
> >>>> cmake provides a generic mechanism to set any variable, either from a
> >>>> command line -DFOO=boo, or via cache files.  But meson didn't provide such
> >>>> standard mechanism AFAICT.
> >>>>
> >>>
> >>> In Meson you must define an option to pass data to the build file.
> >>> This cannot change since it would go against the basic design
> >>> principles of Meson.
> >>>
> >>>> Furthermore, this needs to work both with pkg-config on Linux, and
> >>>> non-pkgconfig on Windows.  We don't want to have one set of meson files that
> >>>> use pkconfig subprojects for Linux, and other that use something else for
> >>>> Windows.
> >>>>
> >>>
> >>> FWIW, a lot of projects use pkg-config on Windows and macOS too since
> >>> pkg-config is a cross-platform standard.
> >>>
> >>> I do understand that it can be a hassle ensuring the existence of
> >>> pkg-config.exe and convincing some projects that they should add
> >>> pkg-config files. Perhaps we can improve that by installing a
> >>> standalone pkg-config.exe with our Windows MSI installers.
> >>
> >> I think it's a mistake for Meson depend on pkg-config.exe on Windows.
> >>
> >> Is completely unfit for purpose IMHO.  cygwin/msys/WSL all might ship
> >> their pkg-config, and who knows what they'll find.
> >>
> >> Plus each project will have specific needs.  Maybe I'm using MSVC 2017.
> >> Maybe I'm using MSVC 2012.  I'll need different static libraries for
> >> those.  There's no such thing as a centralized repository for
> >> dependencies on Windows.  There simply can't be.  At least outside POSIX
> >> ports like cygwin/msys/etc
> >>
> >> An while building all dependencies from source would solve that, that's
> >> also unpractical.  Not only becuase it would take time to convert them
> >> to meson, but also because often source is not available.
> >>
> >>> We also have Windows-specific code in our Sdl2, Boost, Qt, and other
> >>> dependency search classes which is our preferred mechanism to detect
> >>> dependencies that are distributed via installers and can be found in
> >>> 'standard' locations.
> >>
> >> Right.  What Meson lacks is a simple mechanism to generalize that for
> >> any binary package without pkg-config.
> >>
> >>>
> >>>>> for you, we'd love to talk about how we can improve things. For
> >>>>> instance, there were these proposals:
> >>>>> https://github.com/mesonbuild/meson/issues/1525 and
> >>>>> https://github.com/mesonbuild/meson/issues/1524, but we didn't get any
> >>>>> feedback on whether they would actually be useful in real-world usage.
> >>>>
> >>>>
> >>>> I think those were added precisely as a consequence of my discussions with
> >>>> Dylan on porting mesademos.
> >>>>
> >>>> meson subprojects assume too much: they either expect pkg-config, or they
> >>>> expect the subprojects to have source and meson files.
> >>>>
> >>>
> >>> Meson does not require pkg-config to find dependencies, but yes we do
> >>> recommend it because it makes the job very easy.
> >>>
> >>> Meson subprojects exist precisely so you can avoid looking outside the
> >>> source tree for dependencies, so you should not need pkg-config. For
> >>> instance, you can also create a subproject that exports dependency
> >>> objects for pre-built binaries just fine. We should publish an example
> >>> so people know how to do it.
> >>>
> >>>>> Meson is (IMO) unusual in the build systems world in that it's not a
> >>>>> static unchangeable upstream (ala cmake/autotools/scons), but is a
> >>>>> FOSS project that you can interact with, so please talk to us. :)
> >>>>
> >>>>
> >>>> Well, that's a good and a bad thing.  It's certainly great that you're open
> >>>> for discussion.  But I'm afraid the fact that so much interaction is
> >>>> necessary means meson still has some ways to go.  Honestly, besides filing a
> >>>> couple of bugs, I never felt the need to interact with CMake/SCons
> >>>> development community and driver their direction.  It pretty much did what I
> >>>> needed.  I don't want to build a build system myself. And I fear living on
> >>>> the bleeding edge myself.
> >>>>
> >>>
> >>> In my experience, I really wished that cmake/scons upstream cared a
> >>> bit more about my use-cases and I didn't have to hack everything I
> >>> wanted into my build files with macros. ;)
> >>>
> >>> I've found cmake projects to be more fragile and harder to understand
> >>> than even Autotools, but perhaps I'm just looking at badly-written
> >>> build files. This is one of the reasons why Meson restricts what you
> >>> can do in a build file — to make it harder for people to write bad
> >>> ones!
> >>>
> >>>> I'll be honest, I'm happy to evaluate meson as potential replacement build
> >>>> system for SCons.  But to put time in raising meson up to the point where it
> >>>> can be a replacement for SCons is beyond what I'm willing to do.
> >>>>
> >>>
> >>> That's fair, but it seems that there are Mesa developers who are
> >>> interested in doing this, and I do enjoy working with them. The code
> >>> we get is always high quality. :-)
> >>>
> >>>> It seems Meson needs a bit more time to mature and grow a more diverse user
> >>>> community.  It seems a bit lopsided at the moment.  I see no other
> >>>> explanation for us to hit issues with meson that nobody else hit before.
> >>>>
> >>>
> >>> Based mostly on contributions, people are using Meson on all Linux
> >>> distros, all BSDs, Windows, macOS, Solaris, and even Haiku.
> >>>
> >>> Talking specifically about Windows issues, some use it via MSYS/Cygwin
> >>> where these are not problems, others use MSVC and work around these
> >>> issues via the mechanisms I mentioned above or they just bite the
> >>> bullet and port all their dependencies to Meson.
> >>>
> >>>> I do think that wrap patches have lot of potential.
> >>>
> >>> Thanks for the kind words! I'm glad you see what we're aiming for. :)
> >>>
> >>>>    And there was a fullly
> >>>> working wrap paych for glew/freeglut ready to use it would have been a
> >>>> godsend.  But there wasn't.  And they are simply too much for a beginner, or
> >>>> for a team of people to collaborate, specially because they are maintained
> >>>> off tree.
> >>>>
> >>>
> >>> So it seems to me that wrapping binaries is the only major feature
> >>> that is being an obstacle for you to port mesademos? I will publish an
> >>> example for doing that via subprojects, that should help!
> >>
> >> Yes, for mesademos that's the major obstacle I see.  Thanks.
> >>
> >> Jose
> >>
> > 
> > Jose,
> > 
> > Slightly related question, do you guys build LLVM yourselves, or use precompiled
> > binaries from somewhere (and if that's the case where do you get them from)?
> > 
> > Dylan
> 
> Hi Dylan,
> 
> We build LLVM ourselves, from a branch with som backported fixeds, 
> https://cgit.freedesktop.org/~jrfonseca/llvm/commit/?h=backports_33 .
> 
> There are build instructions on mesa/docs/llvmpipe.html
> 
> But I also include a precompiled tarball for MSVC on 
> https://people.freedesktop.org/~jrfonseca/llvm/   This is what gets used 
> in mesa/appveyor.yml
> 
> Jose

Thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: signature
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170922/0f1f6e3a/attachment.sig>