Re: [PATCH libgpiod RFC 0/3] bindings: rust: allow packaging of libgpiod-sys

["Erik Schilling" <erik.schilling@xxxxxxxxxx>]

On Wed May 24, 2023 at 8:03 AM CEST, Viresh Kumar wrote:
> On 23-05-23, 13:25, Erik Schilling wrote:
> > As of now, the Rust bindings are only consumable as git dependencies
> > (and even then come with some restrictions when wanting to control
> > the build and linkage behaviour).
> > 
> > This series does some (hopefully) cleanup and then proposes a change
> > in how the Rust bindings are built and linked.
> > 
> > Since the changes may require people hacking on the bindings to set some
> > additional environment variables (at least if they want to avoid running
> > make install), I am sending this as an RFC in order
> > to hear opinions.
> > 
> > For gpiosim-sys the situation is slightly more complex. Right now,
> > libgpiosim installs without a pkg-config. If it is desireable to add
> > one, that could be done and the same mechanism could be used. Otherwise,
> > if packaging that lib is desirable (it looks like it?), we could either
> > still query for libgpiod (and hope that the linker and include paths are
> > matching) or need some other way to acquire the linker and include paths
> > (and flags).
> > 
> > So... The open questions:
> > - Is this OK at all? Are people depending on this building against
> >   relative paths?
>
> Not sure if the build of the libgpiod git repo depends on that relative path,
> did you try to do `make` in the libgpiod directory ? Like:
>
> $ ./autogen.sh --enable-tools=yes --enable-bindings-rust --enable-examples --enable-tests; make

Ah! I did not catch that libgpiod is built via `make` too. I only
checked the Makefile under libgpiod-sys.

But we can do something like this (I would probably redo the
documentation part in the README then though...):

diff --git a/bindings/rust/libgpiod/Makefile.am b/bindings/rust/libgpiod/Makefile.am
index 38f2ebf..8bbf530 100644
--- a/bindings/rust/libgpiod/Makefile.am
+++ b/bindings/rust/libgpiod/Makefile.am
@@ -2,7 +2,13 @@
 # SPDX-FileCopyrightText: 2022 Linaro Ltd.
 # SPDX-FileCopyrightTest: 2022 Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx>
 
-command = cargo build --release --lib
+# We do not want to build against the system libs here. So we specify the paths
+# to the build directory of the C lib.
+command = SYSTEM_DEPS_LIBGPIOD_NO_PKG_CONFIG=1 \
+               SYSTEM_DEPS_LIBGPIOD_SEARCH_NATIVE="${PWD}/../../../lib/.libs/" \
+               SYSTEM_DEPS_LIBGPIOD_LIB=gpiod \
+               SYSTEM_DEPS_LIBGPIOD_INCLUDE="${PWD}/../../../include/"  \
+               cargo build --release --lib
 
 if WITH_TESTS
 command += --tests

>
> > - What to do with gpiosim-sys (see above)?
>
> The only user for the cargo tests for libgpiod stuff is for the vhost-device
> crate with the help of rust-vmm containers. I am installing libgpiod there
> currently and so it works, not sure of how it may be required to be used later
> on though.

I am not exactly sure if I understood the above comment correctly. But
if we want to eventually be able to consume gpiosim-sys via crates.io
(or any packaging mechanism that relies on cargo package), then we will
need to decouple the header and .so file referencing in a similar way.
The easiest solution for me seems to be to just add a pkg-config file
for gpiosim and use the same mechanism that I sketched for libgpiod-sys
here.