cargo-xcode builds a *.xcodeproj with a static library for my project fine. I struggle to include the header file.
cargo-xcode's documentation refers to https://github.com/sindresorhus/Gifski for an example. The header file there seems to be included with [package.metadata.capi.install.include] in https://github.com/sindresorhus/Gifski/blob/main/gifski-api/Cargo.toml.
This seems to be an instruction for cargo-c. If true, i am not sure how cargo-xcode and cargo-c relate. Does cargo-xcode call cargo-c or am i supposed to call cargo-c myself?
Can anyone refer me to an example or documentation ?
There won't be any C header unless you make one yourself (or generate with cbindgen, but that's a separate tool you still have to use yourself).
cargo-xcode has no support for C headers. cargo-c just calls cbindgen, you don't need cargo-c unless you want the rest of the functionality, like Linux pkg-config generation.
For context: I am trying to assemble an example of using a Rust library from Swift using cargo-xcode and XcodeGen here: https://github.com/kud1ing/Snippets/tree/master/swift_rust.
It's perfectly possible that this is not a problem of using cargo-xcode but of using XcodeGen.
I've already searched the internets for hours but cannot find any example or documentation regarding this use case.
In C, headers and linking of libraries are quite separate. A static library itself has no use for headers. Linking doesn't use headers at all. Library can be linked without using a header.
C headers are needed only by C programs or programs that convert C headers to their own interfaces. These programs only need the header when they're compiled, and can be compiled to object files without access to the static library.
Headers and static libraries are two technically separate things used at different times by different tools. Building executables just hopes – without any checking at all – that they are compatible.
You don't need to try to give the header to cargo-xcode, because it builds a static library and has no use for any headers.
Make the header available to whatever other C/ObjC/Swift you build in any way you like. They totally don't care what happens next and where the library for the header is.
