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

[Jose Fonseca]

On 17/03/17 02:28, Brian Paul wrote:
> On Thu, Mar 16, 2017 at 8:03 PM, Jason Ekstrand <jason at jlekstrand.net
> <mailto:jason at jlekstrand.net>> wrote:
>
>     On March 16, 2017 5:41:24 PM Emil Velikov <emil.l.velikov at gmail.com
>     <mailto:emil.l.velikov at gmail.com>> wrote:
>
>         On 17 March 2017 at 00:21, Dylan Baker <dylan at pnwbakers.com
>         <mailto: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 <http://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.


I don't have any experience with Meson.  But for the record I don't have 
much love for SCons.  I long stopped using SCons for anything but Mesa.

And my have good experience with cmake + ninja/msvc is positive.  So 
tools with similar architecture sound good overall.

In fact, knowing what I know now, if I could go back in time, to when I 
evaluated CMake and SCons, I'd chose CMake.


BTW, it seems that newer SCons will drop Python 2 support [1], which 
might force us to rewrite a lot of SConsfiles/scripts any way.  So 
perhaps that's a good time to evaluate migrating to something else.



That said, moving to another build system is always a herculian task. 
Thought the benefit of having a single build system is appealing and 
might save time down the line.


But there are many questions I have about Meson:  how confident are we 
on Meson?  Are big projects using it?  How sure are we that it won't 
become abandonware in a few years time?  How does it compare with other 
newer gen build systems?


We also have special requirements: one is cross-build from Linux to 
MinGW, which on Mesa case requires building portions of the tree twice 
-- once for host -- another for cross-mingw.


Jose

[1] http://scons.org/scons-251-is-available.html