-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Open
Listed in
Labels
C-tracking-issueCategory: A tracking issue for something unstable.Category: A tracking issue for something unstable.S-needs-designStatus: Needs someone to work further on the design for the feature or fix. NOT YET accepted.Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.S-needs-mentorStatus: Issue or feature is accepted, but needs a team member to commit to helping and reviewing.Status: Issue or feature is accepted, but needs a team member to commit to helping and reviewing.S-waiting-on-feedbackStatus: An implemented feature is waiting on community feedback for bugs or design concerns.Status: An implemented feature is waiting on community feedback for bugs or design concerns.Z-per-package-targetNightly: per-package-targetNightly: per-package-target
Description
Summary
Feature gate: 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
- The interaction with proposals like RFC 3028 does not work well. Selection for targets to build happens at the workspace level instead of at a level where the full compile graph is known. This affects selected packages (target-specific dependencies) and feature resolution as well. There's also some possible confusion, as the per-package-target settings are ignored in dependencies.The exact interaction with feature resolution is a bit up in the air. This may not be super well-tested where in theory each target artifact should get an independently resolved feature graph (ish). Related to: per-package-target unifies features which can conflict with other targets #9521To pick up a draggable item, press the space bar. While dragging, use the arrow keys to move the item. Press space again to drop the item in its new position, or press escape to cancel.
azerupi, phil-opp, luojia65, roblabla, MarkSwanson and 62 more
Metadata
Metadata
Assignees
Labels
C-tracking-issueCategory: A tracking issue for something unstable.Category: A tracking issue for something unstable.S-needs-designStatus: Needs someone to work further on the design for the feature or fix. NOT YET accepted.Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.S-needs-mentorStatus: Issue or feature is accepted, but needs a team member to commit to helping and reviewing.Status: Issue or feature is accepted, but needs a team member to commit to helping and reviewing.S-waiting-on-feedbackStatus: An implemented feature is waiting on community feedback for bugs or design concerns.Status: An implemented feature is waiting on community feedback for bugs or design concerns.Z-per-package-targetNightly: per-package-targetNightly: per-package-target
Type
Projects
Status
Unstable, baking
Milestone
Relationships
Development
Select code repository
Activity
[-]Tracking Issue for XXX[/-][+]Tracking Issue for per-package-target[/+]per-package-target
feature does not work with-Zbuild-std
#9451MarkSwanson commentedon May 29, 2021
#9521
I'm not sure if I should place this here. Just trying to help with keeping track...
FrankvdStam commentedon Jun 3, 2021
See #9537
Airtz commentedon Jul 22, 2021
Another issue is the interaction with
-Zmultitarget
#8176IMO we should be able to do the following:
examples: add simple software task example
examples: add simple software task example
examples: add simple software task example
examples: add simple software task example
examples: add simple software task example
34 remaining items
initial bug discovery (ref rust-lang/cargo#9406)
Qix- commentedon Jan 1, 2024
While testing this with a JSON file as the target path and using
-Zbuild-std
, I get a Cargo panic:Repro here: https://github.com/Qix-/cargo-crash-force-target
Stacktrace
Qix- commentedon Feb 7, 2024
Did some more investigating.
The problem comes down to the following.
-Zbuild-std
requires--target
.--target
is used to populatestd_roots
here:cargo/src/cargo/core/compiler/unit_dependencies.rs
Line 170 in d7d48e4
The failure comes when the given
unit.kind
is not present instd_roots
. I added some debug statements and found thatunit.kind
is populated with an absolute path to the target JSON file. However, since--target
is mandatory in-Zbuild-std
, the argument passed to--target
(e.g.x86_64-unknown-linux-gnu
) is the only one populated instd_roots
. Thus, the index fails.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
std_roots
, or disabling them - even when all targets are#![no_std]
. I'm not sure if this is also used to attachcore
or not, but clearly something isn't getting populated correctly.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
build-std
's future and how it's supposed to work across targets. Sorry for the noise, it's just really hard to track what work has been done and where progress has been made.per-package-target
andbuild-std
#11898mousetail commentedon May 30, 2024
In addition to
forced-target
it would be helpful to have adefault-target
. I generally want to some of the binaries in a workspace to be built for WASM and others for native but do want to keep the option open for people to override and build with some alternate target.My main goal is not to have to type
--target wasm32-unknown-unknown
every time, while still allowing compiling forwasm32-unknown-wasi
orwasm32-unknown-emscripten
. I can add a config file to.cargo
but it will apply to all binaries in a workspace.Ekleog commentedon May 31, 2024
@mousetail There already is a
default-target
parameter. This being said, the use case you depicted does sound likeforced-target
would be the better match for you, this way if people want to cross-compile to other platforms they can pass--target aarch64-unknown-linux-gnu
but still have the WASM blobs be built as WASM.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
-Zbuild-std
to instead be eg.-Zbuild-std=wasm32-unknown-unknown
, and to use the pre-built libstd for any target that is not listed in-Zbuild-std
. But this discussion should likely happen in #9451 (or #11898), as many people are subscribed to this thread :)amnestria commentedon Nov 17, 2024
I've encountered an issue relating to this feature. #14833
carloskiki commentedon Dec 3, 2024
I've been thinking about this feature lately, and I've come to the conclusion that
force-target
is wrong. I can't find where I've seen this proposition, but I think it would better if one could specify a set of target to include or exclude.For example:
Here, only targets with
cfg(target_arch = "arm")
are allowed to build.Here,
wasm
targets are forbidden.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
allow-all-targets-by-default
(terrible name).A simpler, but more tedious option could be something like this:
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
include
andexclude
entries.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
default-target
is useful, because specifying targets to build by default inconfig.toml
is a pain (especially in workspaces, because of the recursive search nature). But also now we solve the problem of trying to compile a crate with a dependency that does not support the user's selected target. This gives cryptic errors and is very annoying for new users (this is especially relevant forwasm
support). This is also great forhal
crates of specific embedded targets, which usually only need to support one or a few targets.jwnrt commentedon Dec 3, 2024
I have been thinking about this too and also thought
force-target
didn't feel right. I was wondering if the allow/deny was more appropriate in a build script which can readTARGET
andCARGO_CFG_TARGET_*
environment variables and give a nice error message.My preferred semantics for
default-target
would be that a crate is compiled for itsdefault-target
when the workspace in general is being built (even when--target
is given) but the--target
flag overrules it when that crate is the "primary" package (i.e. the CWD or the--package
flag is used).The matrix for what a crate would build against would be:
--target
givendefault-target
default-target
--target
givendefault-target
--target
It would also be really useful to set
default-target
to"host"
for situations where one crate in a workspace is executed locally while the others may be retargeted. The most obvious example is where you have anxtask
crate that always runs on the host alongside crates building for embedded targets.I think that would be a change in
rustc
to recognise--target "host"
the same as no flag being set.carloskiki commentedon Dec 4, 2024
Actually, #6179 looks a lot like what we are both talking about. epage's recent comment has a lot of good considerations/inputs.
embassy-rp
& dependencies embassy-rs/embassy#4289