Skip to content

run-make tests fail when configured for multiple targets #11094

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.

Sign up for GitHub

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

Jump to bottom
Closed
brson opened this issue Dec 21, 2013 · 5 comments
Closed

run-make tests fail when configured for multiple targets #11094

brson opened this issue Dec 21, 2013 · 5 comments

Comments

@brson
Copy link
Contributor

brson commented Dec 21, 2013

Something about the use of % seems to make these rules not expand correctly, resulting in

cfg: build triple x86_64-unknown-linux-gnu
cfg: host triples x86_64-unknown-linux-gnu
cfg: target triples x86_64-unknown-linux-gnu i686-unknown-linux-gnu
cfg: non-build target triples i686-unknown-linux-gnu
cfg: enabling more debugging (CFG_ENABLE_DEBUG)
cfg: host for x86_64-unknown-linux-gnu is x86_64
cfg: host for i686-unknown-linux-gnu is i386
cfg: os for x86_64-unknown-linux-gnu is unknown-linux-gnu
cfg: os for i686-unknown-linux-gnu is unknown-linux-gnu
cfg: using gcc
cfg: no llnextgen found, omitting grammar-verification
cfg: including dist rules
cfg: including test rules
make -C x86_64-unknown-linux-gnu/rt/libuv CFLAGS="-Wall  -g -fPIC -m64 " LDFLAGS="-shared -fPIC -ldl -pthread  -lrt -g -m64" CC="gcc" CXX="g++" AR="ar"  builddir="." BUILDTYPE=Release NO_LOAD="run-benchmarks.target.mk run-tests.target.mk uv_dtrace_header.target.mk uv_dtrace_provider.target.mk" V=1
make[1]: Entering directory `/opt/dev/rust3/build/x86_64-unknown-linux-gnu/rt/libuv'
make[1]: Circular libuv.a <- libuv.a dependency dropped.
  ln -f "obj.target/libuv.a" "libuv.a" 2>/dev/null || (rm -rf "libuv.a" && cp -af "obj.target/libuv.a" "libuv.a")
make[1]: Leaving directory `/opt/dev/rust3/build/x86_64-unknown-linux-gnu/rt/libuv'
make: *** No rule to make target `x86_64-unknown-linux-gnu/test/run-make/bootstrap-from-c-with-uvio-1-T-i686-unknown-linux-gnu-H-x86_64-unknown-linux-gnu.ok', needed by `tmp/check-stage1-T-i686-unknown-linux-gnu-H-x86_64-unknown-linux-gnu-rmake.ok'.  Stop.
brson added a commit to brson/rust that referenced this issue Dec 21, 2013
@brson
mk: Work around problem with run-make tests on multiple targets. rust…
675aac3 
…-lang#11094
@huonw
Copy link
Member

huonw commented Mar 2, 2014

part of #8058

@frewsxcv
Copy link
Member

frewsxcv commented Feb 3, 2015

visiting for triage

The FIXME for this issue still exists in the mk/test.mk file, so I assume this is still a valid issue. I'm not well-versed enough in the Make process to know for sure though

@steveklabnik
Copy link
Member

Triage: echoing what @frewsxcv says, but also noting that rustbuild will eventually obviate this.

@alexcrichton alexcrichton mentioned this issue May 3, 2016
Merged
@alexcrichton
Copy link
Member

Make's now gone, so closing.

(rustbuild handles this I believe)

@Eh2406
Copy link
Contributor

Eh2406 commented Sep 3, 2017

There is a FIXME related to this issue,
https://github.com/rust-lang/rust/blob/master/src/tools/compiletest/src/runtest.rs#L2070
Now that the issue is closed can the FIXME be fix, or made more specific?

@oli-obk oli-obk mentioned this issue Sep 6, 2017
Open
nivkner added a commit to nivkner/rust that referenced this issue Mar 17, 2018
@nivkner
remove FIXME(rust-lang#11094) and allow make tests to run on targets …
fd00755 
…besides host
flip1995 pushed a commit to flip1995/rust that referenced this issue Jul 14, 2023
@bors
Auto merge of rust-lang#11094 - y21:issue11084, r=Alexendoo
3f4e599 
[`useless_vec`]: add more tests and don't lint inside of macros

Closes rust-lang#11084.

I realized that the fix I added in rust-lang#11081 itself also causes an error in a suggestion when inside of a macro. Example:
```rs
macro_rules! x {
  () => {
    for _ in vec![1, 2] {}
  }
}
x!();
```
Here it would suggest replacing `vec![1, 2]` with `[x!()]`, because that's what the source callsite is (reminder: it does this to get the correct span of `x!()` for code like `for _ in vec![x!()]`), but that's wrong when *inside* macros, so I decided to make it not lint if the whole loop construct is inside a macro to avoid this issue.

changelog: [`useless_vec`]: add more tests and don't lint inside of macros

r? `@Alexendoo` since these were your tests, I figured it makes most sense to assign you
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@steveklabnik @alexcrichton @brson @frewsxcv @huonw @Eh2406