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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 17/03/17 02:28, Brian Paul wrote:
On Thu, Mar 16, 2017 at 8:03 PM, Jason Ekstrand <jason@xxxxxxxxxxxxxx
<mailto:jason@xxxxxxxxxxxxxx>> wrote:

    On March 16, 2017 5:41:24 PM Emil Velikov <emil.l.velikov@xxxxxxxxx
    <mailto:emil.l.velikov@xxxxxxxxx>> wrote:

        On 17 March 2017 at 00:21, Dylan Baker <dylan@xxxxxxxxxxxxx
        <mailto:dylan@xxxxxxxxxxxxx>> 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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux