Re: [libgpiod]: Meson wrap for libgpiod

["Andrew Jeffery" <andrew@xxxxxxxx>]

Hi Bart,

On Fri, 13 Aug 2021, at 17:14, Bartosz Gołaszewski wrote:
> pt., 13 sie 2021 o 04:24 Andrew Jeffery <andrew@xxxxxxxx> napisał(a):
> >
> > Hi Bartosz,
> >
> > I use libgpiod as part of supporting various platforms in
> > OpenBMC[1][2], among other things. OpenBMC generally targets ARM SoCs,
> > and this means cross-compiling applications and their dependencies as
> > part of the day-to-day work.
> >
> > While cross-compilation for (complex) userspace can be achieved using
> > distro systems like buildroot and openembedded/bitbake or their SDKs,
> > the meson build system[3] provides dependency resolution and (cross)
> > builds as explicit features through subprojects[4] and the wrap package
> > system[5]. In my experience, these features are compelling.
> >
> > To help me develop userspace applications that depend on libgpiod I've
> > opened a pull-request against meson's wrap database[6] to add libgpiod
> > support for v1.6.3:
> >
> > https://github.com/mesonbuild/wrapdb/pull/130
> >
> > Meson overlays this reimplementation of the build system along side the
> > source as shipped in the tag, enabling meson dependency management
> > without any impact on the upstream project. However, as you might
> > guess, the wrap implementation is non-trivial as it transliterates the
> > autotools scripts. While maintenance of this approach doesn't require
> > any work on your part, it does have to adapt as the autotools scripts
> > change. As such:
> >
> > How do you feel about switching from autotools to meson for the build
> > system of libgpiod?
> >
> 
> My main concern is this: I know autotools and feel comfortable using
> it. I don't know meson and would most likely struggle trying to
> maintain this new build system.

No worries! It was a long shot and I wasn't expecting you to actually 
change unless meson piqued your interest :)

> Does it make any sense to have two
> build systems supported at the same time? Possibly with meson files in
> a special 'contrib' directory so that we make it clear it's a
> secondary build system and may not work when something in the
> autotools change?

I think putting it in contrib/ would make it harder to use as generally 
the meson.build files reside alongside the relevant code (just like 
Makefile.am files). Obviously it's possible for both to coexist from 
the root of the repository, but then there's the problem of "clutter" 
from the build system you don't care for. If we take the path of the 
wrapdb I can just make sure things work for each release of libgpiod, 
which removes the uncertainty of whether the two (autotools and meson) 
are in sync and has no maintenance cost for you.

So, maybe it's best if we leave it out-of-tree in meson's wrapdb for 
now? It's easy to experiment with if you wish as all that happens is 
the directory tree from the wrapdb is just copied over the top of the 
libgpiod source tree. The wrapdb will enable meson for those that care 
for it and keep it out of the way unless you choose to switch in the 
future.

If you want to experiment with the wrapdb pull-request, here's how I've 
been testing:

$ # Light test that it does something sensible as a subproject of the wrapdb repo
$ meson setup -Dwraps=libgpiod build && meson compile -C build
$ 
$ # The above creates a subprojects/libgpiod-1.6.3 directory, now build in that as if it weren't a subproject
$ cd subprojects/libgpiod-1.6.3/ &&
> meson setup -Dtools=true -Dtests=true -Dbindings=cxx,python -Dmanpages=true build &&
> meson compile -C build

>From there I've been verifying the output by comparing the following with the autotools install tree:

$ mkdir root && meson install --destdir $(realpath root) -C build && find root | sort

Cheers,

Andrew