[RFC PATCH 0/8] Meson build system

[Pekka Paalanen]

On Wed, 30 Nov 2016 01:02:13 +0000
Emil Velikov <emil.l.velikov at gmail.com> wrote:

> On 29 November 2016 at 20:50, Daniel Stone <daniel at fooishbar.org> wrote:
> > Hey Emil,
> >
> > On 29 November 2016 at 20:41, Emil Velikov <emil.l.velikov at gmail.com> wrote:  
> >> My voice doesn't carry much weight on wayland-devel still I think it
> >> will bring some nice food for thought.
> >>
> >> As you know better than me the actual speed increase isn't in using
> >> Meson, it's due to ninja.
> >>
> >> If one is to use (write?) make backend for Meson the results wouldn't
> >> be that different.  
> >
> > I disagree. Using Ninja is nice, and a huge win, but there is already
> > a massive, massive, massive, win before you invoke either Make or
> > Ninja; just generating the configuration (autoreconf + ./configure vs.
> > meson) is 16.75 seconds on my laptop (again, current-generation Intel
> > with 16GB of RAM) for autotools, vs. 1.24 seconds for Meson. If
> > they're equal, we'd have 53.96s vs. 28.0sec for the total build,
> > rather than 53.96 vs. 12.47.
> >  
> Thanks for the reminder how much configure sucks and how much faster
> non-recursive makefiles are.

> As we build (simple `make') binaries are linked against the in-tree
> DSO(s). Upon `make install' autotools/libtool relinks each binary. The
> latter of which can be quite costly.
> One way around it is to hack into libtool with another to use a
> project called slibtool (I've mentioned it a while back). The latter
> links only once, thus in theory (at least) the whole thing could be
> noticeably faster. For some reason normal linking with slibtool can be
> a bit slow :-(

Hi,

I haven't yet looked at what Meson actually generates, but the
documentation mentioned that one can just run the binaries from the
build tree and they will use the libraries from the build tree
automatically. Would that not imply that the install step must massage
all binaries to have them use installed libs instead of leaving
left-overs from the build setup?

Autotools does it worse: every binary is actually a shell script with
the real binary in a hidder directory, which makes using gdb and
valgrind require a magic libtool incantation, *and* (you say) it also
relinks on install. What's up with that?

How does slibtool achieve the "easy" running of binaries in the build
dir if it does not relink on install?

> >> Last but not least:
> >> Any ideas (did you see any threads) why so many people go and create
> >> their own build system/tools rather than "beating some sense" into the
> >> existing ones ? I'm yet to look into either ones of the autotools
> >> components, having only a cutesy skim through libtool.  

> Please don't get me wrong, autohell^Wautotools is pretty annoying/etc
> at times. Yet again I'm more of a person who would aim to improve
> things before going to plan B.

I'm looking forward to hearing your war stories on trying to beat sense
into autotools. I would never dare even approach it. Maybe it's FUD you
can show to be false, but I kind of doubt it.

One huge convenience of Meson is (the documentation claims) that you
only need the one file 'meson.py' to use it, which makes the dependency
to meson a very easy one. When I look at the list of files installed by
e.g. CMake or autoconf...


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20161130/90355b4b/attachment.sig>