-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Tracking Issue for per-package-target #9406
Comments
#9521 |
See #9537 |
Another issue is the interaction with IMO we should be able to do the following: [package]
forced-target = ["x86_64-pc-windows-msvc", "i686-pc-windows-msvc"] |
While we do have a dedicated repo for RTIC examples, it makes more sense to merge those too with this repo: cargo-rtic-scope, cortem-m-rtic-trace and relevant examples are all interlinked and must be in phase with eachother. However, we can't add it to the workspace yet because per-package-target[0] is not yet stable. [0] rust-lang/cargo#9406
While we do have a dedicated repo for RTIC examples, it makes more sense to merge those too with this repo: cargo-rtic-scope, cortem-m-rtic-trace and relevant examples are all interlinked and must be in phase with eachother. However, we can't add it to the workspace yet because per-package-target[0] is not yet stable. [0] rust-lang/cargo#9406
While we do have a dedicated repo for RTIC examples, it makes more sense to merge those too with this repo: cargo-rtic-scope, cortem-m-rtic-trace and relevant examples are all interlinked and must be in phase with eachother. However, we can't add it to the workspace yet because per-package-target[0] is not yet stable. [0] rust-lang/cargo#9406
While we do have a dedicated repo for RTIC examples, it makes more sense to merge those too with this repo: cargo-rtic-scope, cortem-m-rtic-trace and relevant examples are all interlinked and must be in phase with eachother. However, we can't add it to the workspace yet because per-package-target[0] is not yet stable. [0] rust-lang/cargo#9406
While we do have a dedicated repo for RTIC examples, it makes more sense to merge those too with this repo: cargo-rtic-scope, cortem-m-rtic-trace and relevant examples are all interlinked and must be in phase with eachother. However, we can't add it to the workspace yet because per-package-target[0] is not yet stable. [0] rust-lang/cargo#9406
While we do have a dedicated repo for RTIC examples, it makes more sense to merge those too with this repo: cargo-rtic-scope, cortem-m-rtic-trace and relevant examples are all interlinked and must be in phase with eachother. However, we can't add it to the workspace yet because per-package-target[0] is not yet stable. [0] rust-lang/cargo#9406
While we do have a dedicated repo for RTIC examples, it makes more sense to merge those too with this repo: cargo-rtic-scope, cortem-m-rtic-trace and relevant examples are all interlinked and must be in phase with eachother. However, we can't add it to the workspace yet because per-package-target[0] is not yet stable. [0] rust-lang/cargo#9406
Performing some exhaustive tests when attempting to resolve #9451 revealed that #9521 is likely a duplicate of it, all thanks to a very specific panic message that shows when an attempt to compile a |
I tried to set forced target to
Any idea what could be causing this? The project compiles fine with |
Hmm this looks bad indeed. Do you have an example workspace to reproduce? (Replacing all the code with empty files should most likely still allow reproducing, I'd guess only keeping the Cargo.toml files should be enough) |
I made a test repository here. You should get something like this when compiling
Interesting |
Also related: #10518. |
I'm having the same |
It looks like it might be related to a |
cargo-features = ["per-package-target", "profile-rustflags"] don't work together.
Will fail with |
Also ran into this:
when running Had
Stack backtrace: 0: std::backtrace::Backtrace::create 1: ::msg:: 2: ::activated_features_int 3: cargo::core::compiler::unit_dependencies::new_unit_dep_with_profile 4: cargo::core::compiler::unit_dependencies::compute_deps 5: cargo::core::compiler::unit_dependencies::deps_of 6: cargo::core::compiler::unit_dependencies::deps_of 7: cargo::core::compiler::unit_dependencies::deps_of 8: cargo::core::compiler::unit_dependencies::deps_of 9: cargo::core::compiler::unit_dependencies::deps_of_roots 10: cargo::core::compiler::unit_dependencies::build_unit_dependencies 11: cargo::ops::cargo_compile::create_bcx 12: cargo::ops::cargo_compile::compile_ws 13: cargo::ops::cargo_compile::compile 14: cargo::commands::check::exec 15: cargo::cli::main 16: cargo::main 17: std::sys_common::backtrace::__rust_begin_short_backtrace:: 18: std::rt::lang_start::<()>::{closure#0} 19: std::rt::lang_start_internal 20: _main', src/tools/cargo/src/cargo/core/resolver/features.rs:321:14 stack backtrace: 0: 0x1012b2328 - ::fmt::hcc0d0be5d915b423 1: 0x1012d31c4 - core::fmt::write::hd192c56b84d0d5fc 2: 0x1012ad4c4 - std::io::Write::write_fmt::hc875b6ab61d117f8 3: 0x1012b213c - std::sys_common::backtrace::print::hfdc3c075d7f207b2 4: 0x1012b3ddc - std::panicking::default_hook::{{closure}}::h9a29056d92273910 5: 0x1012b3b34 - std::panicking::default_hook::h918749fa9e3bbd56 6: 0x1012b42ec - std::panicking::rust_panic_with_hook::h115b7bf8f2adb68e 7: 0x1012b4220 - std::panicking::begin_panic_handler::{{closure}}::h610771468070e0bf 8: 0x1012b2748 - std::sys_common::backtrace::__rust_end_short_backtrace::h84374e7a8d4c9564 9: 0x1012b3f7c - _rust_begin_unwind 10: 0x10133cfe4 - core::panicking::panic_fmt::heb926c9af39e8a59 11: 0x10133d31c - core::result::unwrap_failed::h0edb6ed598db9dd6 12: 0x100c67424 - cargo[b7a945c812b2d771]::core::compiler::unit_dependencies::new_unit_dep_with_profile 13: 0x100c64f00 - cargo[b7a945c812b2d771]::core::compiler::unit_dependencies::compute_deps 14: 0x100c63b08 - cargo[b7a945c812b2d771]::core::compiler::unit_dependencies::deps_of 15: 0x100c63cb4 - cargo[b7a945c812b2d771]::core::compiler::unit_dependencies::deps_of 16: 0x100c63cb4 - cargo[b7a945c812b2d771]::core::compiler::unit_dependencies::deps_of 17: 0x100c63cb4 - cargo[b7a945c812b2d771]::core::compiler::unit_dependencies::deps_of 18: 0x100c63970 - cargo[b7a945c812b2d771]::core::compiler::unit_dependencies::deps_of_roots 19: 0x100c62a70 - cargo[b7a945c812b2d771]::core::compiler::unit_dependencies::build_unit_dependencies 20: 0x100f60fe0 - cargo[b7a945c812b2d771]::ops::cargo_compile::create_bcx 21: 0x100f5f4d4 - cargo[b7a945c812b2d771]::ops::cargo_compile::compile_ws 22: 0x100f5f3bc - cargo[b7a945c812b2d771]::ops::cargo_compile::compile 23: 0x100b0c22c - cargo[4ef0020e058ba257]::commands::check::exec 24: 0x100adbc60 - cargo[4ef0020e058ba257]::cli::main 25: 0x100b1474c - cargo[4ef0020e058ba257]::main 26: 0x100ab90b0 - std[d7a38f31206b4b19]::sys_common::backtrace::__rust_begin_short_backtrace:: 27: 0x100aa6bf4 - std[d7a38f31206b4b19]::rt::lang_start::<()>::{closure#0} 28: 0x1012a6824 - std::rt::lang_start_internal::hfc06c7bfe3f9fee2 29: 0x100b16a9c - _main |
How is this feature intended to interact with My motivation here is similar to #8112: I want to execute |
Please let's get some attention on this! |
While testing this with a JSON file as the target path and using Repro here: https://github.com/Qix-/cargo-crash-force-target Stacktrace
|
Did some more investigating. The problem comes down to the following.
The failure comes when the given The debug stacktrace with the print statements is as follows (and is better than the one in my previous comment):
So this new feature isn't properly setting up the This is as far as I've gotten, but in the chance I don't get any further I wanted to post this here. @Ekleog if you have any idea on how this could be fixed and want to give me some pointers (and don't have time yourself) I'm happy to take a whack at a fix. I'm pretty green to the Cargo codebase. EDIT: I'm pretty sure this feature needs a LOT more attention from someone who knows Cargo intimately as there is a lot happening that doesn't seem right when it comes to building a single crate multiple times for different targets during a single Cargo run. See #11898 for more. EDIT2: Looks like there's a lot of different work being done surrounding this exact issue, none of which is being tracked together. Would be nice to have some sort of clarity what the Cargo team wants (maybe there already is, but I can't find a single source for it) when it comes to |
In addition to My main goal is not to have to type |
@mousetail There already is a Unfortunately both default-target and forced-target have several known bugs, and I don't have any time to look into it, plus this was my first contribution to the cargo codebase so I'm not that proficient with the other features either and fixing them (or even understanding them) would require much more time than I can currently allocate to it :/ @Qix- Sorry to have missed your tag! About tracking the various issues and work being done on it, theoretically it should all be reachable from the top post of this issue, which is editable by any maintainer of the cargo repo. For #11898, it sounds close to #9451 listed in the top comment. Do you want me to add an unresolved issue for it in the top comment, or should it be tracked alongside #9451? And in the first case, can you edit the title of #11898 so that it's obvious how it's different? As for the fix to the issue you mentioned, unfortunately I don't have much more to add to what you already wrote. IMO the fix would be to change |
I've encountered an issue relating to this feature. #14833 |
I've been thinking about this feature lately, and I've come to the conclusion that For example: [target.'cfg(target_arch = "arm")']
allowed = true Here, only targets with [target.'cfg(target_family = "wasm")']
allowed = false Here, I don't know the semantics yet, but I think that generally one should only "allow a subset of targets" or "disallow a subset of targets" (not both). There are a multitude of ways we could solve this like failing at compile time, having a unification algorithm, or having another field like A simpler, but more tedious option could be something like this: disallowed-targets = [
"wasm32-unknown-emscripten",
"wasm32-unknown-unknown",
"wasm32-wasi",
"wasm32-wasip1",
"wasm32-wasip1-threads",
"wasm32-wasip2"
] allowed-targets = [
"thumbv8m.base-none-eabi",
"thumbv8m.main-none-eabi",
"thumbv8m.main-none-eabihf"
] The exact names/semantics need to be bikeshedded, but I think it is obvious we need to handle the case where both fields are set. We could do something like the I don't know how any of this should work with custom targets. Although I prefer the first solution, I think both are better than what we currently have. The functionality of setting a |
I have been thinking about this too and also thought My preferred semantics for The matrix for what a crate would build against would be:
It would also be really useful to set I think that would be a change in |
Actually, #6179 looks a lot like what we are both talking about. epage's recent comment has a lot of good considerations/inputs. |
Summary
Feature gate:Nightly: per-package-target
per_package_target
Discussion: https://internals.rust-lang.org/t/proposal-move-some-cargo-config-settings-to-cargo-toml/13336
Implementation: #9030
Documentation: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#per-package-target
Issues: Z-per-package-target
Unresolved issues
-Zbuild-std
The text was updated successfully, but these errors were encountered: