[Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Jason Ekstrand]

On March 16, 2017 5:41:24 PM Emil Velikov <emil.l.velikov at gmail.com> wrote:
> On 17 March 2017 at 00:21, Dylan Baker <dylan at pnwbakers.com> wrote:
>> Hi Emil,
>>
>> Quoting Emil Velikov (2017-03-16 16:35:33)
>>> While I can see you're impressed by Meson, I would kindly urge you to
>>> not use it here. As you look closely you can see that one could
>>> trivially improve the times, yet the biggest thing is that most of the
>>> code in libdrm must go ;-)
>>
>> Perhaps I wasn't clear enough, I don't really expect this to land ever. I sent
>> it out more because I'd written it and it works and is a useful 
>> demonstration of
>> meson+ninja performance. Obviously 20 seconds -> 5 seconds isn't a huge 
>> deal :);
>> but in a larger project, consider that a 4x speedup would be 4 minutes to 1
>> minute, and that is a huge difference in time.
>>
> You are still failing to see past your usecase. As said before - if
> there's any need to improve things say so.
> Note that you simply cannot apply the 1000x speedup in any situation.

Yes, you can't just linearly apply any scaling factor.  However, when you 
build mesa on a machine with a decent number of threads (I think our build 
machine for the CI system has 32 threads), autotools+make is slow as mud.  
Also, there's very little you can do to speed up configure since it's a 
pile of shell and perl that inherently runs single-threaded and is fairly 
complex due to mesa's complicated dependencies.

>>> As the port is not 1:1 wrt the autoconf one, the performance numbers
>>> above are comparing apples to oranges.
>>
>> I fail to see what I'm missing from meson that would have an effect on the
>> times I reported. There are some files that are installed by autoconf that I
>> didn't bother to install with meson (because I don't expect this to land). 
>> Since
>> I didn't time installs, I don't see how it isn't an apples to apples 
>> comparison.
>>
> You already (explicitly) mentioned some differences. Admittedly not a
> deal breaker.
>
>> I understand that libdrm is a pessimal case for recursive-make since most
>> sub folders contain < 5 C files, However, even if you were to flatten the make
>> files meson+ninja would still be faster when you consider that meson
>> configures and builds faster than autotools configures.
>>
> That's correct. If is so concerned - they should slim down the configure.ac ;-)

There are real limits as to what you can do there.

>>> If you/others are unhappy with the build times of libdrm - poke me on
>>> IRC. I will give you some easy tips on how to improve those.
>>>
>>> You have some good python knowledge - I would kindly urge you to
>>> improve/rewrite the slow and/or hacky python scripts we have in mesa.
>>> This is a topic that was mentioned multiple times, and a part where
>>> everyone will be glad to see some progress.
>>>
>>> Thanks
>>> Emil
>>
>> The real goal here is to do mesa (in case I didn't make that clear either), and
>> the advantage for mesa is not just performance, it's that meson supports visual
>> studio on windows; which means that we could hopefully not just get faster
>> builds, but also replace both autotools and scons with a single build system.
>>
> Yes that was more than clear. Yet it won't fly, I'm afraid.
>
> The VMWare people like their SCons,

How much?  I would really rather the VMWare people speak on behalf of 
VMWare.  Meson is the single best shot we've ever had for replacing both 
with one build system.  I'm sure the VMware people would like to have a 
build system that gets maintained by the community as a whole.

> and Meson is not a thing on neither BSD(s), Solaris (and derivatives) nor 
> Android :-\

I have trouble bringing myself to care.  The BSDs need to stop using 10 
year old compilers.  It can be made to work on Solaris and BSD if someone 
bothered to put a little work into it.  Besides, given that large chunks of 
GNOME are switching they're going to have to make it work some day soon anyway.

Android is a bit unfortunate.  Mesa is one of the few projects that let's 
the Android people carry their build system in-tree and I would like to 
keep that going if it were practical.  Dylan and I have talked about this a 
decent bit and one potential solution is to see if the meson people would 
accept an Android back-end.  Then we would be down to a single build system 
(wouldn't that be nice).

> If there's something "slow" say what/where and we can improve upon
> things. You seems to be rewriting $world because someone sold you that
> A is the holy grail.

I don't think that's fair.  No, Meson is not the holy grail but it is the 
closest anyone has yet been able to come to a viable autotools replacement.

Speed is only one aspect to this.  Unifying the Linux and windows builds is 
also a significant advantage.  Also, autotools is objectively terrible and 
having a build system that's modifiable be mere humans without the need for 
hours of pouring over documentation only to find that you did it wrong 
anyway is a definite plus.