Re: [libgpiod][WIP PATCH 0/2] Convert the build from autotools to meson

["Andrew Jeffery" <andrew@xxxxxxxx>]

On Tue, 6 Dec 2022, at 05:25, Bartosz Golaszewski wrote:
> On Mon, Dec 5, 2022 at 2:22 PM Andrew Jeffery <andrew@xxxxxxxx> wrote:
>>
>> Hello,
>>
>> Based on a recent poke [1] and in-between meetings I've put together a
>> WIP series that converts libgpiod's build from autotools to meson. As
>> far as I'm aware the meson build supports all the significant options to
>> enable or disable features exposed by the autotools build:
>>
>> * Tests
>> * Tools
>>   * Interactive gpioset
>> * Bindings
>>   * C++
>>   * Python
>>   * Rust
>> * Documentation
>>   * Manpages
>>   * Doxygen
>>
>> [1] https://lore.kernel.org/all/CAMRc=Mda8UnyH+_GxeX_4MyKd+DPN0BVH5K+J+VWnMJNC1vwTQ@xxxxxxxxxxxxxx/
>>
>> Meson has pretty good support for handling python and so the patch does
>> away with setup.py entirely.
>
> Eek! No, please do keep setup.py. Autotools too is capable of building
> python C extensions on its own and it's what we use in v1 but I want
> the python code to be built the standard python way. I actually plan
> to post libgpiod v2 on pypi and split out building python bindings
> into a separate bitbake recipe in meta-openembedded using the
> setuptools3 class.
>
> So let's keep setup.py and just call it from meson.

Okay. As I was working my way thought I did wonder whether it might be 
better to split out the bindings where they have their own build 
systems (python, rust) so the relationships go one direction. Currently 
we have the library build system referring to the bindings referring to 
the library which seems like a kinda awful sandwich. This is evident in 
the build.rs files for the rust libraries.

>
>> However, the rust case isn't quite so
>> simple. In order to handle the dependencies of the rust bindings I've
>> called out to cargo through a custom target. It's not great, but from
>> what I could see it seems to be the path of least resistance given
>> meson's support for rust.
>>
>> There's no support for installing the rust bindings through meson, but
>> this is not worse than the support we appeared to have under autotools.
>>
>
> I think Viresh too wants to keep cargo as the building agent for the rust code.

Right; I think this is the only sensible approach given current rust 
support in meson.

>
>> It's worth noting that you'll probably want to disable the rust bindings
>> if you need to run the install phase for libgpiod under e.g. sudo but
>> have used rustup to install cargo for your unpriviledged user.
>>
>
> Current autotools setup doesn't install rust bindings at all, can we
> keep it this way?

It is that way in what I've posted, but `meson install` re-runs part of the
build phase which is what causes complications in this specific scenario. If
you can run cargo as root then it shouldn't interfere (... setting aside
potential issues running cargo as root). I didn't figure out whether I could
*avoid* re-building the custom target in the install phase.

>>
>> We end up with a net reduction of 254 LOC for the build system, and,
>> IMO, a single and fairly readable language to express it. Along with
>> that comes easy integration as a dependency in other (meson) projects
>> and a straight-forward path for their cross-compilation.
>>
>> Let me know what you think.
>
> Meson has a steep learning curve but I really want to move over to it
> now and will put in the time to learn it. Thanks for doing it. The
> patches are functional from what I tested so far.

Great!

>
> One thing I'd love to see changed is: put all API and ABI version
> number next to each other in a single place so that there's less risk
> of forgetting to update one of them when making a release. Is that
> possible?

Absolutely. In the spirit of keeping things that are together together 
I distributed them into the meson.build file containing the 
specification of the associated library target. But we can just move 
those variables into the root meson.build file without any problems.

Andrew