On Mon, Aug 01, 2022 at 05:41:06PM +0530, Viresh Kumar wrote:
On 27-07-22, 13:17, Kent Gibson wrote:
On Wed, Jul 27, 2022 at 10:21:58AM +0530, Viresh Kumar wrote:
On 27-07-22, 10:57, Kent Gibson wrote:
On Fri, Jul 08, 2022 at 05:04:54PM +0530, Viresh Kumar wrote:
+fn main() {
- let files = vec![
"../../../lib/chip.c","../../../lib/chip-info.c","../../../lib/edge-event.c","../../../lib/info-event.c","../../../lib/internal.c","../../../lib/line-config.c","../../../lib/line-info.c","../../../lib/line-request.c","../../../lib/misc.c","../../../lib/request-config.c",- ];
- #[cfg(feature = "generate")]
- generate_bindings(&files);
- build_gpiod(files);
+}
Shouldn't bindings wrap libgpiod and dynamically link against it rather than building and linking statically?
There are few problems I faced, because of which I had to do it this way.
I couldn't find a way to do a "Make" for libgpiod from here and then link to the resultant library.
libgpiod may not be automatically installed in the environment where the end user of these Rust APIs exists. So I had to build it.
And then the API is changing a lot, maybe down the line once it is stable enough we can change this to something else.
Sure, it is a problem, but static isn't the solution. You should be able to get the appropriate paths from autoconf, but I would refer you to Bart on that.
I am still looking for some help on how to link this dynamically.
FWIW, the problem is that the user crates, like vhost-device, will mention libgpiod as a dependency crate and likely won't have libgpiod installed in environment. So build.rs here needs to do some magic so the definitions are all available to the users.
The Rust bindings themselves should be building against the local build tree, so well known relative paths.
For users, require they have libgpiod installed and use pkg_config to locate it?
Is that what you mean?
Else, how do other Rust crates wrapping dynamic C libraries do it?
Cheers, Kent.