Avoid including manifest into a library built from a crate with both a binary and library
Opened this issue · 4 comments
If you just use the crate as described in the README.md, the manifest will also end up in the library crate and linked to crates depending on this crate. This should be documented and avoided if at all possible, as the manifest is often only meant for the binary, or for a cdylib if built and so on, but not for the rlib, or crates that depend on the crate using this crate.
This should be documented and avoided if at all possible, as the manifest is often only meant for the binary
I agree.
Related: #8. Insufficient control and confusion about which binary will have the resource applied.
Note that this can actually get tricky when making winresource optional (e.g. For a feature that gates the binary). And also considering cross compilation, where I think cfg stuff in build scripts gets tricky as the build script is built for the host.
Note that this can actually get tricky when making shadow-rs optional
I can't quite follow - winresource does not depend on shadow-rs.
And also considering cross compilation, where I think cfg stuff in build scripts gets tricky as the build script is built for the host.
Oh yeah, I've already been dealing with this a lot. This is documented in the Readme and also talked about in some of the issues.
I can't quite follow - winresource does not depend on shadow-rs.
Typo. Meant winresource.