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

[Brian Paul]

On Thu, Mar 16, 2017 at 8:03 PM, Jason Ekstrand <jason at jlekstrand.net>
wrote:

> 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.
>

Sure, I'd like to see one build system instead of two.  Meson supports
Windows so that's good.  But the big issue is our automated build system.
Replacing SCons with Meson could be a big deal in that context.  It would
at least involve pulling Meson into our toolchain and rewriting a bunch of
Python code to grok Meson.  I'd have to go off and investigate that to even
see if it's a possibility.  Maybe next week.

-Brian


>
> 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.
>
>
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170316/218d64ae/attachment-0001.html>