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

[Dylan Baker]

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
-------------- 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/34cbc175/attachment-0001.sig>