cargo-c
cargo-c copied to clipboard
Document that the capi feature must be present in the Cargo.toml
If my Cargo.toml
does not contain a [features]
section defining the capi
feature, the header file is generated correctly, but the dynamic library does not contain the expected symbols.
The README says:
You may use the feature
capi
to add C-API-specific optional dependencies.
... but it doesn't say that defining this feature is required.
UPDATE: I'm trying this on Linux, btw.
Do you have your code available so I can take a look?
I've created #153 as an example.
The error appears in CI.
It works as intended.
cargo rejects setting features that aren't present in the manifest. I cannot work around this limitation without changing the cargo API.
This can be quite confusing, because the header contains all the functions, but the library doesn't. Would it at least be possible to have the header file and the library contain (or not contain) the same functions?
The instruction "... use #[cfg(feature="capi")]
to hide it when you build a normal rust library" from the README should not be separated from the instruction "You may use the feature capi
to add C-API-specific optional dependencies.", because those two are not independent.
Still, even with updated documentation, this might cause a lot of confusion in the future, it would be great if it were possible to avoid the problem completely ...
What was the reason for deprecating #[cfg(cargo_c)]
?
Using this would avoid the problem.
there are two issues:
- setting
cfg(cargo_c)
works but not for the tests because of howcargo rustc
works, relaxing this constraint requires patching cargo. - adding on the fly features to the manifest requires patching cargo to add a setter for it.
On top cbindgen
is happy to ignore cfg(feature="capi")
.
Possibly I can send patches to upstream cargo to get those two sorted.
In the meantime, the README contains the information that the capi
feature is obligatory.
But maybe it would be helpful to explicitly mention how to do that?
Something like this:
[features]
capi = []
It sounds a good idea indeed. :)