-
-
Notifications
You must be signed in to change notification settings - Fork 106
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cargo rustc --crate-type
support
#433
Comments
This is currently not the case, but there is no technical reason preventing this aside from requiring a higher minimum rust version. The |
Edit: I spoke too soon--see my next message. |
I spoke too soon. It appears crate-type isn't working as I had expected?
Cargo.toml
via # In Debug builds, we are forced to use .dll due to incompatible _ITERATOR_DEBUG_LEVEL values: 0 in cc-rs via Rust and 2 in C++.
# In release builds we should prefer static libraries, though, due to minimize failure points during the update process.
if (CMAKE_BUILD_TYPE STREQUAL "Debug")
set(RECURSIVE_CPP_CRATE_TYPE cdylib)
else()
set(RECURSIVE_CPP_CRATE_TYPE staticlib)
endif()
corrosion_import_crate(MANIFEST_PATH source/gctex/Cargo.toml CRATE_TYPES ${RECURSIVE_CPP_CRATE_TYPE} FLAGS --crate-type=${RECURSIVE_CPP_CRATE_TYPE}) Adding |
Could you clarify what is broken? The expected behavior is that |
For context, I have a crate that I import directly with Cargo (gctex), but is also used as a library by pure Rust code; I cannot make a dylib wrapper library easily as I don't think it'll export transitive symbols. I was looking for a way to only opt-in to cdylib on Windows Debug, and totally remove that value from the TOML file. |
Okay, let's see if I understood correctly:
|
Yes. In particular, here is the error I get trying:
via [package]
name = "test2"
version = "0.1.0"
edition = "2021"
[dependencies]
gctex = { path = "../gctex"} Despite the fact that test2 presumably should only care about the rlib artifact, it appears to build all of gctex's targets.. for some reason. |
I suspect that cargo doesn't really know what kind of |
A use case that seems to be related here is building icu4x. The icu_capi crate that provides the FFI does not have a crate-type specified (and based on feedback, they say they are unable to add this), so Corrosion cannot find it. Otherwise the build would work fine using the technique from the crate_type example - verified by patching Corrosion to force a "staticlib" crate type rather than extracting it from the manifest. |
Added in #557 |
Motivation: Compiling a project for multiple targets, it can often be necessary to have both a cdylib and staticlib version of a crate. Unfortunately, on some targets (WASM) cdylibs are a build error. There is no good way to conditionally have build types, and the Rust team appears to have no interest in adding that, in favor of
cargo rustc
with--crate-type
.For an example of its usage, see rust-lang/cargo#10356
This is the RFC rust-lang/rfcs#3180 (comment)
Information on conditional staticlib/such and why that probably isn't coming: rust-lang/cargo#4881 (comment)
I believe ideally in corrosion, we would simply not require cdylib/staticlib be specified in Cargo.toml and pass the crate type from
corrosion_import_crate
? Is this feasible?The text was updated successfully, but these errors were encountered: