Better support for --llvm-root.
#27937
Conversation
|
r? @brson (rust_highfive has picked a reviewer for you, use r? to override) |
| $$(S) | ||
| $$(S) \ | ||
| "$$(LLVM_LIBDIR_RUSTFLAGS_$(3))" \ | ||
| "$$(shell $$(LLVM_CONFIG_$(3)) --components)" |
There was a problem hiding this comment.
Can this output be cached in a variable to prevent re-running it?
|
The travis failures here look like they may not be benign |
DiamondLovesYou
force-pushed
the
llvm-root-and-shared
branch
3 times, most recently
from
8bfc6cd to
320cc47
Compare
|
Can this hold off on the changes to tests/maketest for now? The changes to compiletest are only needed if tests are linking to the compiler (e.g. fulldeps), but for most targets with custom LLVM builds we probably don't need the compiler itself working there just yet, so fixes like this can come later if absolutely necessary. Same with the changes to run-make as I believe run-make isn't run for target-only targets (as opposed to host+target targets). I continue to be very wary of landing all these changes as it's quite a deal of difficult logic that isn't tested in any way, so I prefer to minimize the impact as much as possible. |
|
@alexcrichton They were due to variable expansions happening before |
…mode. This is a change needed for rust-lang#27937, so that `-L $(llvm-config --libdir)` is only added to RUSTFLAGS for fulldeps based compiletest modes.
DiamondLovesYou
force-pushed
the
llvm-root-and-shared
branch
from
320cc47 to
8a345c5
Compare
|
Looks like good cleanup. I agree that the additional complexity in compiletest is unwarranted for now. Maybe we can fix this problem some other way and I'm happy to ignore all fulldeps tests on the web for a while. |
|
@brson I'm not sure I understand what you mean by "I'm happy to ignore all fulldeps tests on the web for a while". Could you explain exactly what you mean? Also, surely the benefit of the fulldep tests outweighs the pretty minimal additional complexity in |
|
Currently running the fulldeps tests means that the entire compiler has to be built for the target platform, and in this case that probably isn't necessary. I believe @brson means that in the interest of keeping this minimal (e.g. only running the Unfortunately "minimal complexity" ends up being bitrotted very quickly without being exercised which ends up porting it forward for a few years or so only to be painfully deleted at some point. |
|
Following up on some discussion on #28327: The current patch does not work for my use case, and I don't think the LLVM patch mentioned in the #28327 discussion is going to help, because I don't have a |
|
Is your system's LLVM built with CMake && BUILD_SHARED_LIBS I'll have to add an extra flag to On Thu, Sep 10, 2015 at 12:14 PM, wthrowe notifications@github.com wrote:
|
|
Yes, it looks like it uses CMake with |
|
☔ The latest upstream changes (presumably #28421) made this pull request unmergeable. Please resolve the merge conflicts. |
|
Just fyi: we in Gentoo are interested in the possibility to link Rust to separated LLVM shared libraries, otherwise we can't use the system wide LLVM which is quite sad from the point of view of the overall build time. |
LLVM in Gentoo is shipped as static libs only now, until Rust upstream fixies linking using system wide LLVM is impossible see rust-lang/rust#27937 -Werror during Rust building was disabled
DiamondLovesYou
force-pushed
the
llvm-root-and-shared
branch
3 times, most recently
from
95e6097 to
f8e9e86
Compare
DiamondLovesYou
force-pushed
the
llvm-root-and-shared
branch
from
6e60fff to
b2c4317
Compare
|
Ready to go. |
| $$(LLVM_CONFIG_$(1)) "$(CFG_STDCPP_NAME)" | ||
| $(Q)$(CFG_PYTHON) "$$<" "$$@" "$(filter $(shell \ | ||
| $(CFG_LLVM_ROOT)/bin/llvm-config$(X_$(CFG_BUILD)) \ | ||
| --components), \ |
There was a problem hiding this comment.
Can this be replaced with a variable defined below to avoid re-invoking llvm-config?
There was a problem hiding this comment.
No, because we don't want to link unused LLVM components into rustc.
There was a problem hiding this comment.
I mean, I don't have a problem with just linking everything, I just thought you guys might not like it.
|
I have a feeling that this is likely to break over time (as there's no CI and this looks pretty brittle as so many build system things are), but it seems fine as it should be easy to get back up to speed in the future. |
|
☔ The latest upstream changes (presumably #30157) made this pull request unmergeable. Please resolve the merge conflicts. |
DiamondLovesYou
force-pushed
the
llvm-root-and-shared
branch
from
7026709 to
049042e
Compare
|
Ok, the point about re-invoking |
DiamondLovesYou
force-pushed
the
llvm-root-and-shared
branch
from
049042e to
abc6e7a
Compare
|
Done! |
|
@bors: r+ abc6e7ae8be975119ad92814fe815059aeea18e7 |
|
⌛ Testing commit abc6e7a with merge 3b5e8bf... |
|
💔 Test failed - auto-mac-64-nopt-t |
This handles cases when the LLVM used isn't configured will the 'usual' targets. Also, cases where LLVM is shared are also handled (ie with `LD_LIBRARY_PATH` etc).
DiamondLovesYou
force-pushed
the
llvm-root-and-shared
branch
from
abc6e7a to
7bd69f2
Compare
|
Whoops, I forgot to push a change to |
…ichton This handles cases when the LLVM used isn't configured will the 'usual' targets. Also, cases where LLVM is shared are also handled (ie with `LD_LIBRARY_PATH` etc).
It looks like rust-lang#27937 accidentally switched the llvmdeps file from the target to the host by accident, so be sure to use the right llvmdeps file which is built for the target when building rustc_llvm
It looks like #27937 accidentally switched the llvmdeps file from the target to the host by accident, so be sure to use the right llvmdeps file which is built for the target when building rustc_llvm
LLVM in Gentoo is shipped as static libs only now, until Rust upstream fixies linking using system wide LLVM is impossible see rust-lang/rust#27937 -Werror during Rust building was disabled
This handles cases when the LLVM used isn't configured will the 'usual' targets. Also, cases where LLVM is shared are also handled (ie with
LD_LIBRARY_PATHetc).