This is catching misconfiguration. For example one of my automation
had a typo running -DLLVM_ENABLE_PROJECTS=nlir and it was just
silently ignored. Instead, an error will now be displayed.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
CMake Error at CMakeLists.txt:76 (MESSAGE): all isn't a know project: clang;clang-tools-extra;compiler-rt;cross-project-tests;libc;libclc;libcxx;libcxxabi;libunwind;lld;lldb;mlir;openmp;parallel-libs;polly;pstl;flang;llvm
llvm/CMakeLists.txt | ||
---|---|---|
67 | I added debuginfo-tests in 4b80f0125adc876c8ef325f1c0ace4af023f2264 |
llvm/CMakeLists.txt | ||
---|---|---|
67 | Wasn't this renamed to cross-project-tests? |
llvm/CMakeLists.txt | ||
---|---|---|
67 | See 1364750dadbb56032ef73b4d0d8cbc88a51392da Move debuginfo-test into a subdirectory of a new top-level directory, called cross-project-tests. The new name replaces "debuginfo-test" as an LLVM project enabled via LLVM_ENABLE_PROJECTS. |
llvm/CMakeLists.txt | ||
---|---|---|
67 | Ah, my LLVM_ENABLE_PROJECTS had debuginfo-tests so my build was broken. My debuginfo-tests/ was not empty because there were many __pycache__ .pyc files... I'll revert the commit. Sorry |
This is a problem for us (chromium). We inject an extra target at the cmake level and then pass that to LLVM_ENABLE_PROJECTS. That used to work fine, but now it's rejected.
How should we proceed?
- Put this check behind a (default-on) option and turn it off for us
- Add a setting of valid extra project names that's default-empty
- Your idea here
I didn't quite get the "inject" part?
How should we proceed?
- Put this check behind a (default-on) option and turn it off for us
- Add a setting of valid extra project names that's default-empty
Any of these could work.
- Your idea here
Actually we already have a flag for that: -DLLVM_EXTERNAL_PROJECTS which is intended to be used to declare projects that aren't "known" (see https://llvm.org/docs/CMake.html )
Aren't you able to use this?
Any of these could work.
Cool, did the first version in 55f0b337087136554122f942fea951a357bc4a49.
Actually we already have a flag for that: -DLLVM_EXTERNAL_PROJECTS which is intended to be used to declare projects that aren't "known" (see https://llvm.org/docs/CMake.html )
Aren't you able to use this?
We tried it a while ago and ran into a bunch of issues, see https://bugs.chromium.org/p/chromium/issues/detail?id=962988&q=LLVM_EXTERNAL_PROJECTS&can=2
Seems like this was fixed a couple of weeks after the last comment in this bug? https://reviews.llvm.org/D62289
Seems like this was fixed a couple of weeks after the last comment in this bug? https://reviews.llvm.org/D62289
We're trying again: https://chromium-review.googlesource.com/c/chromium/src/+/3172772 If it works out, we can remove LLVM_CHECK_ENABLED_PROJECTS again.
llvm/CMakeLists.txt | ||
---|---|---|
71 | Shouldn't LLVM_EXTERNAL_PROJECTS be appended to LLVM_KNOWN_PROJECTS ? Otherwise it would fail when a external project is configure with -DLLVM_EXTERNAL_PROJECTS=foo-project -DLLVM_ENABLE_PROJECTS=foo. If so, the loop enabling the projects should just loop on LLVM_KNOWN_PROJECTS. |
llvm/CMakeLists.txt | ||
---|---|---|
71 | From what I read line 129, you don't use LLVM_ENABLE_PROJECTS for external projects. |
llvm/CMakeLists.txt | ||
---|---|---|
71 | You are right, external projects should not be passed in LLVM_ENABLE_PROJECTS. Thanks for pointing that out. |
I added debuginfo-tests in 4b80f0125adc876c8ef325f1c0ace4af023f2264