| Message ID | 20230522-crates-io-v1-0-42eeee775eb6@linaro.org |
|---|---|
| Headers | show |
| Series | bindings: rust: allow packaging of libgpiod-sys | expand |
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 > - 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. > - Is there interest into getting this published on crates.io after > packaging is fixed? Yes.
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@linaro.org> -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.
On 24-05-23, 10:09, Erik Schilling wrote: > 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. Yes we would like to get gpiosim via crates.io as well.
On Tue, May 23, 2023 at 1:26 PM Erik Schilling <erik.schilling@linaro.org> 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? > - What to do with gpiosim-sys (see above)? > - Is there interest into getting this published on crates.io after > packaging is fixed? > > Signed-off-by: Erik Schilling <erik.schilling@linaro.org> > --- > Erik Schilling (3): > bindings: rust: drop legacy extern crate syntax > bindings: rust: remove unneeded cc dependency > bindings: rust: build against pkg-config info > > README | 13 ++++++++++- > bindings/rust/libgpiod-sys/Cargo.toml | 5 ++++- > bindings/rust/libgpiod-sys/build.rs | 42 ++++++++++++++++++++++------------- > 3 files changed, 42 insertions(+), 18 deletions(-) > --- > base-commit: 0a51d62f060dbc1b036dfd45e52d4d90f0ce3eeb > change-id: 20230522-crates-io-773a0b6b423d > > Best regards, > -- > Erik Schilling <erik.schilling@linaro.org> > I applied the first two patches, I'll wait for the respon of 3/3. Bart
On 5/24/23 10:14, Viresh Kumar wrote: > On 24-05-23, 10:09, Erik Schilling wrote: >> 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. > > Yes we would like to get gpiosim via crates.io as well. Would simply adding a pkg-config for the gpiosim C lib be desirable? Then we can use the same mechanism. There is none existing at the moment. I am not sure whether that is intentional or just not done yet. - Erik
>>> 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. >> >> Yes we would like to get gpiosim via crates.io as well. > > Would simply adding a pkg-config for the gpiosim C lib be desirable? > Then we can use the same mechanism. There is none existing at the > moment. I am not sure whether that is intentional or just not done yet. @Bartosz: Viresh said on IRC that I should ask you about this :). Shall I just add a pkg-config for gpiosim? Or is that not desired for some reason? - Erik
On Fri, 26 May 2023 at 10:30, Erik Schilling <erik.schilling@linaro.org> wrote: > > > > >>> 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. > >> > >> Yes we would like to get gpiosim via crates.io as well. > > > > Would simply adding a pkg-config for the gpiosim C lib be desirable? > > Then we can use the same mechanism. There is none existing at the > > moment. I am not sure whether that is intentional or just not done yet. > > @Bartosz: Viresh said on IRC that I should ask you about this :). Shall > I just add a pkg-config for gpiosim? Or is that not desired for some reason? > > - Erik libgpiosim was not meant to be installed for development, that's why there's no pkg-config for it. We don't install the header and only install the shared object if tests are enabled but with the expectation that the tests were built in-tree. I also don't quite get why we'd want to get gpiosim via crates.io - I would prefer to use the one in the tree. Or am I not understanding something here right? Bart
On 5/26/23 10:36, Bartosz Golaszewski wrote: > On Fri, 26 May 2023 at 10:30, Erik Schilling <erik.schilling@linaro.org> wrote: >> >> >> >>>>> 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. >>>> >>>> Yes we would like to get gpiosim via crates.io as well. >>> >>> Would simply adding a pkg-config for the gpiosim C lib be desirable? >>> Then we can use the same mechanism. There is none existing at the >>> moment. I am not sure whether that is intentional or just not done yet. >> >> @Bartosz: Viresh said on IRC that I should ask you about this :). Shall >> I just add a pkg-config for gpiosim? Or is that not desired for some reason? > > libgpiosim was not meant to be installed for development, that's why > there's no pkg-config for it. We don't install the header and only > install the shared object if tests are enabled but with the > expectation that the tests were built in-tree. Ah. Did not catch that the header is not installed. > I also don't quite get why we'd want to get gpiosim via crates.io - I > would prefer to use the one in the tree. Or am I not understanding > something here right? I am also only seeing the libgpiod package using it as dev-dependency. If that is the only consumer and we do not want to expose it to out-of-tree things then that should be fine and we can keep building that one against the "in-tree" artifacts for it. @Viresh: Could you comment on the use-case that you had in mind with gpiosim being on crates.io? I am not seeing any good options to package it if it is only intended as an testing tool for in-tree things. - Erik
On 26-05-23, 10:59, Erik Schilling wrote: > @Viresh: Could you comment on the use-case that you had in mind with gpiosim > being on crates.io? I am not seeing any good options to package it if it is > only intended as an testing tool for in-tree things. I thought vhost-device is already using it for testing, I was wrong :( So we don't need it via crates.io for now at least.
>> @Viresh: Could you comment on the use-case that you had in mind with gpiosim >> being on crates.io? I am not seeing any good options to package it if it is >> only intended as an testing tool for in-tree things. > > I thought vhost-device is already using it for testing, I was wrong :( > > So we don't need it via crates.io for now at least. Thanks for checking! I will then just send an updated patch for libgpiod-sys :). If gpiosim becomes part of the public interface we can revisit the situation then. - Erik
On 5/24/23 11:17, Bartosz Golaszewski wrote:
> I applied the first two patches, I'll wait for the respon of 3/3.
Thanks!
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? - What to do with gpiosim-sys (see above)? - Is there interest into getting this published on crates.io after packaging is fixed? Signed-off-by: Erik Schilling <erik.schilling@linaro.org> --- Erik Schilling (3): bindings: rust: drop legacy extern crate syntax bindings: rust: remove unneeded cc dependency bindings: rust: build against pkg-config info README | 13 ++++++++++- bindings/rust/libgpiod-sys/Cargo.toml | 5 ++++- bindings/rust/libgpiod-sys/build.rs | 42 ++++++++++++++++++++++------------- 3 files changed, 42 insertions(+), 18 deletions(-) --- base-commit: 0a51d62f060dbc1b036dfd45e52d4d90f0ce3eeb change-id: 20230522-crates-io-773a0b6b423d Best regards,