-
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 profile-rustflags #10271
Comments
I see something like this as necessary for the usability of RFC 3028 (artifact dependencies): #9096 . Historically Cargo has not supported passing arbitrary flags in profile overrides because many of them made no sense to pass to a dependency (e.g. That doesn't mean that this feature is the only way to satisfy this need, but I think anything that does satisfy this need would have to be functionally equivalent to profile-rustflags. |
cargo-features = ["per-package-target", "profile-rustflags"] don't work together.
Will fail with |
I can not get this to work with a
It seems like it tries to link the things that should be excluded via |
As mentioned in the unresolved section, profile rustflags get applied to build scripts. You can override that with: [profile.dev.build-override]
rustflags = [] Also, I might suggest using the Conditional settings are not supported in profiles, you'll need to use separate profiles. In the future, please file a new issue if you have a question or problem. See the "About tracking issues" section above. |
Sorry, I will read more carefully next time and create a separate issue instead. I did not realize that my example contained a build script, thanks for the hint! The |
I am getting an issue where workspace rustflags don't work for sub-crates. For example, - in the workspace Cargo.toml: # TODO: Remove when WebGPU is no longer an unstable
[target.'cfg(target_arch="wasm32")'.profile.dev]
rustflags = ["--cfg", "web_sys_unstable_apis"] Subcrates won't compile that depend on this: error[E0599]: no method named `gpu` found for struct `WorkerNavigator` in the current scope
--> /Users/simbleau/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wgpu-0.17.2/src/backend/web.rs:950:18
|
947 | / global
948 | | .unchecked_into::<web_sys::WorkerGlobalScope>()
949 | | .navigator()
950 | | .gpu()
| | -^^^ method not found in `WorkerNavigator`
| |_________________|
Related: #4897 |
This is not a valid key in
|
Confused what you mean by it's not a key. It's documented here: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#profile-rustflags-option |
Can we also have per-profile environment variables, for CFLAGS/CXXFLAGS? Before I make a corresponding issue, is this idea going to fly at all? Rationale: RUSTFLAGS alone is not enough to have, for example, cross-language LTO on the release profile. |
Depends on how you use profile. For now we can leverage BTW I feel like this has been brought up, but couldn't find an issue of it. |
Wrapper for `cargo --profile=release` with a custom config, to make up for absence of per-profile options (flags, env) in (stable) Cargo.
Wrapper for `cargo --profile=release` with a custom config, to make up for absence of per-profile options (flags, env) in (stable) Cargo.
Submodule bin 9be07f2..bc34b46: > wrappers: cargo-rel: workaround for rust-lang/cargo#10271 and co. > lib: bump > wrappers: komake: build an in-tree kernel module as an out-of-tree one > git/misc: git-delete-refs: tee delete commands on stderr > devel: unfuck.sh: cleanup > devel: replace unfuck-*.sh with unfuck.sh > misc: syncthing-curl: do not `curl -f`
Submodule bin 9be07f2..74e6e1c: > etc/easyrsa: add common easyrsa vars for intelfx.name PKIs > lib: bump > git/misc: git-edit: use `git add --intent-to-add` on all changed files > Merge branch 'master' of github.com:intelfx/bin > build-*-full: allow specifying SAN as a command option > easyrsa: init-pki: fix bogus unset when printing the new PKI status > easyrsa: init-pki: actually find vars.example outside of $EASYRSA_PKI > easyrsa: export(pkcs): only check ca.crt > tools: easyrsa: import easyrsa 3.1.7 > misc: promote pkgbuild-* to misc > wrappers: lsblk-pt: `lsblk` with columns about partitions themselves > pass: get.bash: add pass(1) extension to retrieve specific fields in "key: value" format > util: disk-fstrim: always skip BIOS boot partitions (gdisk type EF02) > util: disk-fstrim: use lsblk instead of blkid > util: disk-fstrim: clean up variable usage in pattern contexts > util: disk-fstrim: clean up locals handling > wrappers: cargo-rel: workaround for rust-lang/cargo#10271 and co. > lib: bump > wrappers: komake: build an in-tree kernel module as an out-of-tree one > git/misc: git-delete-refs: tee delete commands on stderr > devel: unfuck.sh: cleanup > devel: replace unfuck-*.sh with unfuck.sh > misc: syncthing-curl: do not `curl -f`
@weihanglo this sounds like a great solution, I just cant get it to work reasonably let's say I have a default configuration that is used during development and in the dev profile. This should be a default and work without an extra command line which could be forgotten, because I want to put things like sanitizer support in there. So this is my [build]
target = "x86_64-unknown-linux-gnu"
rustflags = ["-Z", "sanitizer=address"]
[env]
BUILD_PROFILE = "debug" Now in my build system I want to build the release build with a different configuration and the stable compiler. I create a new [env]
BUILD_PROFILE = "release" And use the command How would you approach such a use case? I have a mixed C and Rust application, that needs different rustflags and environment variables for the debug and release builds. I am really struggling with getting that right. Another really unfortunate thing with defining the |
would love to see this make it to stable :) |
How does this interact with RUSTFLAGS? Do the flags get merged or does one take precedence? |
As of cargo/src/cargo/core/compiler/mod.rs Line 1084 in ec05ed9
|
I am confused -- so both RUSTFLAGS and profile flags are passed? That means there is no precedence as the lists get merged? Saying "passed independently" and "lowest precedence" seems like a contradiction to me. |
By lowest precedence I meant they are passed earlier. Cargo doesn't merge them. Cargo passes them to rustc verbatim. Flags from
|
Ah makes sense, thanks!
|
What if I want to set rustflags per-profile and per-target? e.g. say I want to use the mold linker, but only for Linux, and only for dev profile:
but I can't find a way to do this in the unstable feature documentation. Is it possible? |
@JohnstonJ No. It is another feature request. Per-target profile is tracking under #4897. See also previous comments #10271 (comment). |
It appears to me that this permits Cargo users to expose themselves to potential soundness issues to which they were previously immune. There's a discussion here about it, but the short version is that when the user has control over per-package Rust-flags, they can choose to compile some packages with If my understanding is correct, there should be a prominent warning in the documentation for this feature that by changing the compilation flags for individual crates, the user loses some of the protections typically afforded to Cargo users. Additionally, when this feature is stabilized, the "note" in the "Prohibited Linkage Scenarios" section of the reference (not merged yet) should be changed to acknowledge that this feature enables bypassing Cargo's protection against this particular UB:
|
Generally the expectation is that rustc must ensure that the crates it is linking are actually compatible for linking. So if this cargo feature can be used to cause unsoundness, that sounds like a soundness bug in rustc to me. |
It's not just this feature, though: it's this feature, in conjunction with an FFI call to another language that then starts an unwind operation. Edit: I think I was mistaken; |
Summary
Original issue: #7878
Implementation: #10217
Documentation: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#profile-rustflags-option
The
profile-rustflags
feature allows setting RUSTFLAGS per-profile.Unresolved Issues
cargo test
may fail if they aren't passed to rustdoc. However, rustdoc doesn't accept all of rustc's flags. Adding arustdocflags
option seems to be adding more unwanted complexity, though.build-override.rustflags = []
.TargetInfo
, which impacts feature resolution and other things.Cargo.toml
Future Extensions
No response
About tracking issues
Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
The text was updated successfully, but these errors were encountered: