> > 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