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

[Jose Fonseca]

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