[Mesa-dev] initial meson port

[Eric Anholt]

Matt Turner <mattst88 at gmail.com> writes:

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

Yeah.  You still want tarballs, you just want the tarballs to be
basically a snapshot of git so that everybody's using the same build
system.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170921/93839cc7/attachment.sig>