Re: [OE-core] [PATCH 1/2] systemd: Allow native build

["Böszörményi Zoltán" <zboszor@gmail.com>]

2023. 03. 30. 18:39 keltezéssel, Richard Purdie írta:
> On Thu, 2023-03-30 at 16:10 +0200, Alexander Kanavin wrote:
>> On Thu, 30 Mar 2023 at 16:08, Zoltan Boszormenyi <zboszor@gmail.com> wrote:
>>> Please see the MR:
>>> https://gitlab.freedesktop.org/libfprint/libfprint/-/merge_requests/431
>>>
>>> udev (provided by systemd) -> libgudev -> libfprint
>>> also:
>>> udev-native -> libgudev-native -> libfprint-native -> libfprint
>>>
>>> Also, please read the TODO part of the patch for systemd
>>> and consider it.
>> We can simply direct libfprint to run its own target pieces under qemu
>> usermode, and avoid all this nasty native stuff. Meson has direct
>> support for it, and even if it doesn't work, libfprint can be patched
>> to use a custom 'wrapper' for executing the binaries.
> Before we jump to using qemu user mode, the first question has to be do
> we really need a libgudev native to make libfprint-native work enough
> to build libprintf.
>
> I'd hope the answer is no, we don't as we don't want the build systems
> udev setup/devices leaking into a target build.
>
> We intentionally try and keep native dependencies minimal and needing
> native udev/systemd versions of things sets of warnings in my mind and
> in others since it often means we're doing things we shouldn't be or
> don't actually need.
>
> I appreciate there are issues with systemctl-native but those are
> separate issues and should be addressed as such. Complicating the build
> dependencies unnecessarily is bad and we should minimise them where
> possible. it isn't that I didn't read that bit of the patch, I just
> don't see it as a reason to have this dependency for libfprint.
>
> So, I come back to the question of what libfprint needs from libfprint-
> native and whether it really does need udev for that?

libfprint needs two generator executables to create
a set of udev rules and another file called autosuspend.hwdb.

Both executables are linked with the complete libfprint library
which includes the complete set of drivers that are configured
and built. They seem to need this to deduce the list of supported
device USB IDs for the current build. Both executables use fpi_
prefixed functions to ask the libfprint library for their goals.

In turn, the libfprint library depend on libgudev and libgusb
for hotplug and device discovery purposes, respectively.

There is also a meson bug that Alexander Kanavin brought
to my attention where custom_target() doesn't run executables
using the exe_wrapper and I seem to be hitting this with
libfprint.

I am not a meson expert so if there's a way to replace
the executable()+custom_target(capture: true) combination
with something more cross-compiler friendly, please don't hold
this information back.

I couldn't fix this for libfprint 1.0 / fprintd 0.9.0 two years ago
and I cannot fix it for the 2.0 beta versions either.
In my current in-house solution there's a separate systemd-native.bb
recipe but I thought maybe cleaning it up for upstream and
modifying the systemd recipe may be acceptable.