-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Support custom options for LLVM build #93756
Conversation
(rust-highfive has picked a reviewer for you, use r? to override) |
Hm. So, part of me is enthusiastic about supporting something like this, on the other hand, I wonder if it's worth some kind of disclaimer of "at your own risk" or similar -- part of the strategy I've at least sort of tried to steer by is that if folks are trying to extra-customize LLVM, they may just want to build out of tree entirely and provide an llvm-config. (Obviously, that has its own problems). But I think this is sufficiently general and minimally invasive that I am in general on board with it -- I do wonder if you might be able to ask around and/or have some ideas on other projects embedding LLVM to see if there's some general guidance around the appropriate way to expose this? In particular, with my relatively limited knowledge I'm wondering if just CMAKE defines are typically enough? Or do we need support for general environment configuration / something beyond that? I will also add that if we do land this it's pretty likely we'll want to drop support for at least some of the existing flag in config.toml that we aren't ourselves interested in using/supporting (e.g., polly build). |
cc #93629 and #93640 as well, which seem like prime PRs I would "not accept" in favor of using this feature, though as noted on one of those I might have pushed for just leaving LLVM builds external as well. @catap -- curious if you feel this PR would be enough for you or it's missing something you'd need? |
@Mark-Simulacrum definitely! |
r=me with the comment adjusted and llvm_from_ci! gate added. |
daa4e15
to
69cd826
Compare
@bors r=Mark-Simulacrum |
📌 Commit 69cd826 has been approved by |
@bors rollup=always |
…askrgr Rollup of 7 pull requests Successful merges: - rust-lang#92670 (add kernel target for RustyHermit) - rust-lang#93756 (Support custom options for LLVM build) - rust-lang#93802 (fix oversight in the `min_const_generics` checks) - rust-lang#93808 (Remove first headings indent) - rust-lang#93824 (Stabilize cfg_target_has_atomic) - rust-lang#93830 (Refactor sidebar printing code) - rust-lang#93843 (kmc-solid: Fix wait queue manipulation errors in the `Condvar` implementation) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
I think this also needs an update to |
Ah, or perhaps it'll just work by including the key for the dictionary in |
@jonhoo you may use |
I would expect --set llvm.config.foo=bar to work - do we have something hard coded to two elements in the path? |
@Mark-Simulacrum unfortently it is a bit more tricky. Special when someone needs a few LLVM options. Anyway, some ugly configure set make the job done. |
Yeah, I just tried:
and got
|
@jonhoo |
I can also confirm that I get the same error even if I just set a single key this way. Will try your way now @catap. |
@catap That doesn't look quite right either. It gives me # Custom CMake defines to set when building LLVM.
build-config = '{LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN=1,LLVM_ENABLE_ZLIB=FORCE_ON}' Which sets |
I don't think that's true — I'm running it in bash, and I think that's the right quoting for the command. The problem is that |
@jonhoo let me dig, how I've used it. You're right. |
Separately, I also noticed that the way this is currently implemented, Lines 374 to 376 in 89adcc6
should move to Line 415 in 89adcc6
which all of the three LLVM-based steps use? |
The LLVM build has a lot of options that rustbuild doesn't need to know about. We should allow the user to customize the LLVM build directly.
Here are some example customizations we'd like to do.