[RFC PATCH 0/8] Meson build system

[Pekka Paalanen]

On Wed, 30 Nov 2016 09:21:29 +0000
Daniel Stone <daniel at fooishbar.org> wrote:

> Hi Pekka,
> 
> On 30 November 2016 at 08:54, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > On Wed, 30 Nov 2016 01:02:13 +0000 Emil Velikov <emil.l.velikov at gmail.com> wrote:  
> >> 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 :-(  
> >
> > 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?  
> 
> I'm not sure what slibtool does, but at least for Meson, it's a pretty
> easy answer. The binaries get a DT_RPATH ELF entry for the build tree,
> which makes them look there for libraries first. On install, you don't
> need to relink, but just strip the rpath entry from the binary as you
> install.

Hi,

Ok, so it's massaging all binaries but not relinking. Cool.

> > 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...  
> 
> I would like to agree and say that's great, but I think it's either
> slightly misunderstood or only about half true. Meson itself _can_ be
> 'zipped' into a single Python file indeed, though I haven't actually
> tried this myself: I either use distro packages or use a local install
> via pip.

Yeah, my confusion. It was actually about running from an extracted
tar-ball or git which is practically as good.

https://github.com/mesonbuild/meson/wiki/FAQ#how-to-use-meson-on-a-host-where-it-is-not-available-in-system-packages

> That being said, its effect on the source tree is far better
> than autotools: it generates build.ninja & compile_commands.json
> inside the build directory, and leaves the source directory completely
> untouched. This is markedly better than autotools, which generates a
> huge amount of stuff inside the source directory. From that
> perspective at least, it's far more clean.

Indeed, even if autotools was used for an out-of-tree build.

I'm still in the middle or reading through Meson documentation, will
probably ask more once I finish.


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/1bdc616b/attachment.sig>