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

[Jose Fonseca]

On 21/09/17 09:56, Nirbheek Chauhan wrote:
> On Thu, Sep 21, 2017 at 1:53 PM, Jose Fonseca <jfonseca at vmware.com> wrote:
>> On 12/04/17 18:57, Nirbheek Chauhan wrote:
>>>
>>> Hi Jose,
>>>
>>> On Wed, Apr 12, 2017 at 11:08 PM, Jose Fonseca <jfonseca at vmware.com>
>>> wrote:
>>>>
>>>> One newbie question: what's your workflow to update a wrap patch?  Can we
>>>> prototype changes locally without tarballing the patch?
>>>>
>>>
>>> Any changes you make in subproject directories will be kept as-is;
>>> Meson only initializes them and will not try to update them (yet), so
>>> you can apply your patches to the subproject directory manually for
>>> testing.
>>>
>>> In the future, we want to improve this workflow, of course.
>>>
>>
>> Hi Dylan,
>>
>> FYI I didn't forget about this.  But I have to say that having to maintain
>> and fix these wrap modules seperately from git is simply a huge turn off
>> everytime I think about resuming this.
>>
>> I think it's was a mistake to try to make meson wrap modules for 3rd party
>> dependencies.  Especially when these wrap modules involve glue that's not
>> tracked in git, so it can't be esasily revved, or shared across the people
>> working on this.   If we simply had a way to consumed built binaries like we
>> can easily do with cmake, I'm confident it would have been trivial to get
>> this going by now.
>>
>> But as it stands I don't think overcome this wall.  Honestly, I don't want
>> have to deal with porting glew/freeglut to meson just to get mesademos with
>> meson, and I really shouldn't have to.  I don't want to build the world just
>> mesademos.
>>
> 
> That is not a requirement in general, only a requirement if you want
> to use glew/freeglut as a subproject (which requires meson build
> files). Meson will be able to find libraries stored anywhere on the
> system as long as you either:
> 
> a) Set the correct env variables for the compiler library and include
> paths[1], or
> b) Set the `dirs:` keyword argument to cc.find_library() and set the
> right include paths, or
> c) Set PKG_CONFIG_PATH if your libraries ship pkg-config files
>
> This is very similar to cmake, fwict. 

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.

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.

However, if this doesn't work
> 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 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.

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.

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.

> The main advantage of adding a wrap patch for a project is to speed up
> (and make it easy to have) integration builds that build the entire
> stack, but the most common usage of Meson is to build against
> pre-existing binaries. We could probably make the experience better on
> Windows, but we need feedback to do that!
> 
> Cheers,
> Nirbheek
> 
> 1. `LIB`/`INCLUDE` with MSVC and `LIBRARY_PATH`/`C_INCLUDE_PATH` for gcc/clang

I do think that wrap patches have lot of potential.  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.


Jose