[Mesa-dev] initial meson port

[Matt Turner]

On Thu, Sep 21, 2017 at 5:06 AM, Jakob Bornecrantz <wallbraker at gmail.com> wrote:
> On Thu, Sep 21, 2017 at 2:20 AM, Eric Anholt <eric at anholt.net> wrote:
>> Dylan Baker <dylan at pnwbakers.com> writes:
>>> Results
>>> autotools : sh -c   535.34s user 30.33s system 310% cpu 3:02.05 total
>>> meson     : sh -c   136.58s user 11.98s system 372% cpu 39.895 total
>>
>> I just want to point at these numbers again.  meson is so transformative
>> for your normal build/test cycles that it's worth it even if we have to
>> duplicate source lists.  I know these aren't quite representative
>> because of all of automake's checks that haven't been done for meson,
>> but here's what we had for the X server conversion:
>>
>>                         autotools:   meson:
>> no-op build              0.83         0.49
>> touch Makefile.am        1.28
>> touch configure.ac      16.68
>> touch meson.build                     2.92
>> clean ccache build      16.74         1.44
>> clean build             52.24        27.84
>>
>> Hopefully we can replace two of our build systems (hopefully android and
>> scons?) with this one, and then I think it will definitely be less
>> developer build system maintenance, even with duplicated source lists.
>> I'd be curious to hear what the vmware folks would need from meson in
>> order to drop scons, and I'd be willing to put in a good bit of work to
>> make it happen.
>>
>> Additionally, meson doesn't need the .hs listed in its source lists, so
>> these meson.builds are actually more verbose than we need and would drop
>> a huge source of our "fix up the build system" patches for automake's
>> stupid distcheck.
>
> Wasn't lacking distcheck support one of the arguments against moving
> to only a scons build when this was brought up all those years ago?
> Does Meson provide something similar, or do people just now get all
> of the source from git nowadays?

Maybe that discussion was a before my time (or maybe I've just
forgotten) but I did all of the work to make "make dist" work in
~2013. Building the tarballs and generating files like configure makes
sense given the workings and limitations of autotools. I'd definitely
be opposed to not making the tarballs with autotools' dist target
because since we've switched we haven't shipped a broken tarball once,
which was a common occurrence previously.

With switching to Meson though, there's not the same need to generate
all sorts of things and include them in the tarball. We'd add
dependencies on python, mako, flex, and bison that we don't currently
require to build from a tarball, but I think that's an acceptable
cost.

Just to preempt the question: as a (source-based) distribution
maintainer, I'm against just getting the code from git. There's lots
of distro infrastructure in place to mirror files and not any that I'm
aware of to handle git repos.