Re: [libgpiod]: Meson wrap for libgpiod

Hi Bart,

On Fri, 13 Aug 2021, at 17:14, Bartosz Gołaszewski wrote:

pt., 13 sie 2021 o 04:24 Andrew Jeffery [off-list ref] napisał(a):

quoted

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