Re: [libgpiod][bug] building rust bindings requires clang headers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > Setting PKG_CONFIG_PATH will only work if you point it at the install
> > folder of libgpiod.
>
> Correct - that is exactly what I did.
>
> > If you do not want to install, you will need to set
>
> Yeah, I don't install on my dev machine - I deploy to separate machines
> for testing.  For dev I just want to be able to use the same workflow I
> would use for a general rust project, so cargo XXX, and purely in the
> code tree.  At least that is what I was doing previously.

I agree that there is _some_ friction, but I did not come up with a way
to preserve the old behavior without the risk of being confusing for
consumers of the lib (or even people attempting to compile things where
libgpiod-sys is just a transitive dependency).

The current solution mostly resembles how most of the Rust bindings
that I know work. But I acknowledge that those bindings are usually
developed in repositories separate from the underlying lib. Are there
good examples how other libs are solving this problem?

> > See https://lore.kernel.org/r/20230522-crates-io-v2-2-d8de75e7f584@xxxxxxxxxx/
> > on why it had to become a little bit ugly for rust bindings hackers.
>
> I understand why you might be changing things to be able to package the
> crates, but in an ideal world that wouldn't impact normal workflow.
> Or it would be simple to switch.

I fear the ideal world where there is no impact may be hard to achieve.
When building with make, we _know_ that the C lib is also built, but
when building from cargo, there is no good way (that I know of) to
differ between a build that just happens because someone is building
from crates.io or a developer invoking cargo sub-commands. Ideally, a
build from local source should also show identical behavior compared to
a build from the registry.

Also, we will (at least in the future) need an easy way to build against
different versions of the C lib. For me the easiest way seems to be to
install different libgpiod versions to some non-system path and then
use PKG_CONFIG_PATH to switch... That just allows us to use standard
mechanisms without requiring to reinvent any wheels.

> > Maybe we should put that example back to the README.md (or into the top-
> > level README?)
> > 
>
> Sounds like a plan to me.  I would go with the rust specific README.
> Or add a file that can be sourced to setup the build environment to get
> cargo working from the command line.

I started with the README. Sent as part of my series of last crates.io
publishing tweaks:

https://lore.kernel.org/r/20230612-crates_io_publish-v1-0-70988ee9a655@xxxxxxxxxx

- Erik




[Index of Archives]     [Linux SPI]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux