You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The outputted header from cbindgen seems to be consistently false. There are no errors or anything, but it appears the invocation of cargo expand is yielding an empty result. Not quite sure how to debug this one.
I'm running cbindgen from within a build script, like so:
fnmain(){#[cfg(feature = "header")]generate_header();}#[cfg(feature = "header")]fngenerate_header(){::cbindgen::Builder::new().with_language(::cbindgen::Language::C).with_include_guard("ORO_BOOT_H").with_namespace("oro_boot").with_item_prefix("oro_boot_").with_parse_deps(true).with_parse_expand(&["src/lib.rs"]).with_parse_expand_all_features(true).generate().expect("Failed to generate bindings").write_to_file("/tmp/oro_boot.h");}
The library itself has a bunch of #[repr(C)] pub structs that are defined both using macros as well as standalone, without any macro usage. I'll try to poke around and figure out what's going on but cargo-expand is able to expand these just fine (understanding it's its own binary), so I wonder if it's really an issue with cbindgen or if cargo-expand uses some other mechanism to expand.
EDIT: In fact, removing everything but the simple structs (including removing the #[no_std], etc) still results in an empty header.
EDIT2: Even building with +stable doesn't make any difference.
EDIT3: Running directly via cbindgen CLI works if I just have a single pub const FOO:usize=1234; in there but anything more complex results in an empty output header, too. This is with a config toml being specified along with expand config.
EDIT4: I added a log line that outputs the command line for expanding and it appears to expand just fine. cbindgen isn't using that information though.
I originally thought this was a problem with the use of target configs but it wasn't. Original issue here:
Compiling with a custom --target appears to cause cargo expand to fail. Perhaps adding a way to pass additional cargo expand arguments would be helpful here?
failed to generate header: CargoExpand("test-cbindgen", Compile("error: extra arguments to `rustc` can only be passed to one target, consider filtering\nthe package by passing, e.g., `--lib` or `--bin NAME` to specify a single target\n"))
stack backtrace:
0: rust_begin_unwind
at /rustc/fcc325f1bc477975e2ce5ba534fe4c77ff8a8536/library/std/src/panicking.rs:665:5
1: core::panicking::panic_fmt
at /rustc/fcc325f1bc477975e2ce5ba534fe4c77ff8a8536/library/core/src/panicking.rs:74:14
2: core::result::unwrap_failed
at /rustc/fcc325f1bc477975e2ce5ba534fe4c77ff8a8536/library/core/src/result.rs:1679:5
3: core::result::Result<T,E>::expect
at /rustc/fcc325f1bc477975e2ce5ba534fe4c77ff8a8536/library/core/src/result.rs:1059:23
4: build_script_build::generate_header
at ./build.rs:8:17
5: build_script_build::main
at ./build.rs:3:2
6: core::ops::function::FnOnce::call_once
at /rustc/fcc325f1bc477975e2ce5ba534fe4c77ff8a8536/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
The text was updated successfully, but these errors were encountered:
The outputted header from cbindgen seems to be consistently false. There are no errors or anything, but it appears the invocation of cargo expand is yielding an empty result. Not quite sure how to debug this one.
I'm running
cbindgen
from within a build script, like so:However all that gets generated is this:
The library itself has a bunch of
#[repr(C)] pub struct
s that are defined both using macros as well as standalone, without any macro usage. I'll try to poke around and figure out what's going on butcargo-expand
is able to expand these just fine (understanding it's its own binary), so I wonder if it's really an issue with cbindgen or ifcargo-expand
uses some other mechanism to expand.EDIT: In fact, removing everything but the simple structs (including removing the
#[no_std]
, etc) still results in an empty header.EDIT2: Even building with
+stable
doesn't make any difference.EDIT3: Running directly via
cbindgen
CLI works if I just have a singlepub const FOO:usize=1234;
in there but anything more complex results in an empty output header, too. This is with a config toml being specified along withexpand
config.EDIT4: I added a log line that outputs the command line for expanding and it appears to expand just fine. cbindgen isn't using that information though.
I originally thought this was a problem with the use of target configs but it wasn't. Original issue here:
Compiling with a custom
--target
appears to cause cargo expand to fail. Perhaps adding a way to pass additional cargo expand arguments would be helpful here?The text was updated successfully, but these errors were encountered: