[Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson
Jose Fonseca
jfonseca at vmware.com
Wed Mar 22 17:59:10 UTC 2017
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
More information about the dri-devel
mailing list