examples/rust: Store skeletons in $OUT_DIR#248
Conversation
Store skeletons in $OUT_DIR as opposed to .output, which is kind of the proper thing to do (though it certainly doesn't help discoverability...) and it is more in line with how examples in libbpf-rs work. Also remove the "there is hope!" comments, because even with rust-lang/rust#83366 resolved we still cannot use the concat! macro in #[path = ...] attributes. All hope is lost. Signed-off-by: Daniel Müller <deso@posteo.net>
The example need to include the correct vmlinux.h header for the current architecture if they aim to build on arches other than x86. Adjust the logic accordingly. Fixes: libbpf#247 Signed-off-by: Daniel Müller <deso@posteo.net>
c3bfe7d to
ffe6e98
Compare
anakryiko
left a comment
There was a problem hiding this comment.
Do you think it's possible to support something like that in libbpf-cargo itself, so that users don't have to duplicate this logic all the time?
Either way, landing as it is an improvement that fixes a real problem, thanks!
I thought about it, but it's not clear to me how that would be possible in a generic fashion. It would probably mean that we'd have to ship the headers ourselves, which is ugly. The cleanest solution would be to unconditionally extract the header from BTF, which has its own downsides. It's going to be a mess either way, it seems. |
All that seems like an overkill, agreed. I think for libbpf-bootstrap we should just create directory symlinks to match Rust's ARCH values, and avoid those matches. |
Store skeletons in $OUT_DIR as opposed to .output, which is kind of the proper thing to do (though it certainly doesn't help discoverability...) and it is more in line with how examples in libbpf-rs work. Also remove the "there is hope!" comments, because even with rust-lang/rust#83366 resolved we still cannot use the concat! macro in #[path = ...] attributes. All hope is lost.