[RFC PATCH 0/8] Meson build system [for libinput this time]

[Peter Hutterer]

On Thu, Dec 08, 2016 at 12:39:18PM +0000, Daniel Stone wrote:
> Hey Peter,
> 
> On 7 December 2016 at 22:33, Peter Hutterer <peter.hutterer at who-t.net> wrote:
> > On Tue, Nov 29, 2016 at 04:59:39PM +0000, Daniel Stone wrote:
> >> [meson is like totally super duper]
> >
> > I tried the same for libinput, work available in
> > https://github.com/whot/libinput/tree/wip/meson
> > I think I'm about 80% of the way there, with more testing needed and a few
> > details being different/missing.
> 
> Neat!
> 
> I think you need to filter the compiler flags list with
> cc.has_argument() to work everywhere - but this is true of
> Wayland/Weston as well. You could also replace the has_paired_device()
> check with cc.has_function('libwacom_has_paired_device', dependencies:
> dep_libwacom).
> 
> 0.36.0 also lets you get rid of some of the more ugly
> '@0@/bar'.format(foo) with join_paths(foo, '/bar') instead. I'm going
> to update Wayland/Weston to make use of this
> 
> include_directories('.') for libinput shouldn't be needed - I assume
> this is just there to pick up libinput-version.h, which you can do
> instead by adding libinput_version_h to the libinput sources list.

oh, right. just copy/pasted those I guess. There's some other polish to be
done, this will be tidied up once we get some rough plan of whether we
switch everything or not. Thanks for the review though.

> Are you sure this generates the right soversion for libinput? It looks
> like you've got args from libtool's -version-info (something I never
> quite managed to figure out), whereas Meson just takes the soversion
> directly (a la libtool -version-number).

probably not, I haven't looked at that yet. as you said I just took the
libtool version. 

> The rest looks good to me!
> 
> > benchmark results are below, but they're more limited than the weston one.
> > Running the test suite as part of the build process is pointless as it can
> > easily take half an hour. There's only one make clean/rebuild we have to
> > worry about unlike weston's multiple rebuild types.
> >
> > It's a bit apples to oranges because I opted for a single meson.build file
> > instead of the current recursive automake, so some of the speedup is likely
> > caused by that. Documentation build is currently missing, but that's just a
> > doxygen run. If anyone wants to run the numbers on different machines please
> > do so, I just ran it with JOBS=4 on my T440s, i7-4600U CPU @ 2.10GHz, 12GB
> > RAM, make -j4. I re-ran with -j8 but the numbers were almost identical
> > anyway.
> 
> Flat vs. multiple files makes no difference for Meson. Weston
> distributes it into multiple files, but they all land in one
> build.ninja file anyway.

It make a difference to automake though, so for a real comparision we'd have
to have a non-recursive automake. But I'm not really enthused about doing
*that* work ;)

Cheers,
   Peter

> > Aside from the faster build times, meson's language feels a lot cleaner than
> > autotools. I'm generally opposed to non-recursive Makefiles because they get
> > messy, I didn't mind it here. So I'd be quite ok with switching to meson
> > (after some more testing of course).
> 
> Great. :) It'll probably be another week / few days before I get to
> respin the Meson work, as I want to get atomic (+ lots of other stuff
> on top) v2 out first. But it's really neat! Glad you liked it.
> 
> Cheers,
> Daniel