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.