Skip to content
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

-Zhost-config doesn't apply host.rustflags to build-script-builds #10206

Closed
Tracked by #9453
Nemo157 opened this issue Dec 16, 2021 · 2 comments · Fixed by #10395
Closed
Tracked by #9453

-Zhost-config doesn't apply host.rustflags to build-script-builds #10206

Nemo157 opened this issue Dec 16, 2021 · 2 comments · Fixed by #10395
Labels
C-bug Category: bug Z-host-config Nightly: host-config Z-target-applies-to-host Nightly: target-applies-to-host

Comments

@Nemo157
Copy link
Member

Nemo157 commented Dec 16, 2021

Problem

When using -Zhost-config to add in rustflags to apply to the host-only builds, these are still not passed to rustc when building build-scripts.

Steps

> cargo new foo && cd foo
     Created binary (application) `foo` package
> echo 'fn main() { assert!(cfg!(foo)); }' > build.rs
> cargo build -Zhost-config -Ztarget-applies-to-host -Zunstable-options --config 'host.rustflags=["--cfg=foo"]'
   Compiling foo v0.1.0 (/tmp/tmp.9cICAJ9mce/foo)
error: failed to run custom build command for `foo v0.1.0 (/tmp/tmp.9cICAJ9mce/foo)`

Caused by:
  process didn't exit successfully: `/home/nemo157/.cargo/shared-target/debug/build/foo-ba25a7af077036f3/build-script-build` (exit status: 101)
  --- stderr
  thread 'main' panicked at 'assertion failed: cfg!(foo)', build.rs:1:13
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Possible Solution(s)

I believe the issue is around here, this should be still applying the host rustflags to the build-script builds

if requested_kinds != [CompileKind::Host] && kind.is_host() {
// This is probably a build script or plugin and we're
// compiling with --target. In this scenario there are
// no rustflags we can apply.
return Ok(Vec::new());
}

Notes

Originally mentioned on the tracking issue; but after more thought I'm fairly confident this is a bug.

Version

cargo 1.59.0-nightly (a359ce160 2021-12-14)
release: 1.59.0-nightly
commit-hash: a359ce16073401f28b84840da85b268aa3d37c88
commit-date: 2021-12-14
host: x86_64-unknown-linux-gnu
libgit2: 1.3.0 (sys:0.13.23 vendored)
libcurl: 7.80.0-DEV (sys:0.4.51+curl-7.80.0 vendored ssl:OpenSSL/1.1.1l)
os: Arch Linux [64-bit]
@alexcrichton
Copy link
Member

I believe that this is a known bug of -Ztarget-applies-to-host which needs fixing internally in Cargo.

@jonhoo
Copy link
Contributor

jonhoo commented Feb 17, 2022

Fix in #10395.

jonhoo pushed a commit to jonhoo/cargo that referenced this issue Feb 18, 2022
bors added a commit that referenced this issue Feb 28, 2022
Enable propagating host rustflags to build scripts

### What does this PR try to resolve?

This PR primarily fixes #10206, but in doing so it also slightly modifies the interface for the unstable `target-applies-to-host` feature (#9453), and adds the unstable `target-applies-to-host-kind` flag to mirror `target-applies-to-host` for build scripts and other host artifacts.

The commit messages have more in-depth discussion.

### How should we test and review this PR?

The test case from #10206 now works rather than producing an error. It has also been added a regression test case. A few additional test cases have also been added to handle the expected behavior around rustflags for build scripts with and without `target-applies-to-host-kind` enabled.

### Additional information

1. This changes the interface for `target-applies-to-host` so that it does not need to be specified twice to be used. And it can still be set through configuration files using the `[unstable]` table. However, we may(?) want to pick a stable format for in-file configuration of this setting unless we intend for it to only ever be a command-line flag.
2. It may be that `target-applies-to-host-kind` is never behavior we want users to turn on, and that it should therefore simply be removed and hard-coded as being `false`.
3. It's not entirely clear how `target-applies-to-host-kind` should interact with `-Zmultitarget`. If, for example, `requested_kinds = [HostTarget, SomeOtherTarget]` and `kind.is_host()`, should `RUSTFLAGS` take effect or not? For the time being I've just hard-coded the behavior for single targets, and the answer would be "no".
@bors bors closed this as completed in 4f41727 Feb 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: bug Z-host-config Nightly: host-config Z-target-applies-to-host Nightly: target-applies-to-host
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants