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

[Emil Velikov]

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.

>>
>> 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 ;-)

>> 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, and Meson is not a thing on
neither BSD(s), Solaris (and derivatives) nor Android :-\
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'll repeat my earlier request - your python skills/knowledge will be
greatly appreciated in existing parts of Mesa.
Speaking of which - you last work doesn't seem to have landed. What's
blocking it ?

Thanks
Emil