Fix various tool libraries not to link to clang's .a libraries and dylib
simultaneously. This may cause breakage, in particular through
duplicate command-line option declarations.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
For the record, this seems to trigger some command-line option parser problem:
******************** TEST 'Clang Tools :: clang-tidy/infrastructure/invalid-command-line.cpp' FAILED ********************
Script:
--
: 'RUN: at line 1'; not clang-tidy --invalid-arg 2>&1 | FileCheck /home/mgorny/git/llvm-project/clang-tools-extra/test/clang-tidy/infrastructure$
invalid-command-line.cpp
--
Exit Code: 1
Command Output (stderr):
--
/home/mgorny/git/llvm-project/clang-tools-extra/test/clang-tidy/infrastructure/invalid-command-line.cpp:4:16: error: CHECK-NEXT: expected string no
t found in input
// CHECK-NEXT: clang-tidy{{(\.exe)?}}: Did you mean '--extra-arg'?
^
<stdin>:2:1: note: scanning from here
clang-tidy: Did you mean '--enable-pre'?
^
Input file: <stdin>
Check file: /home/mgorny/git/llvm-project/clang-tools-extra/test/clang-tidy/infrastructure/invalid-command-line.cpp
-dump-input=help describes the format of the following dump.
Full input was:
<<<<<<
1: error: [CommonOptionsParser]: clang-tidy: Unknown command line argument '--invalid-arg'. Try: 'clang-tidy --help'
2: clang-tidy: Did you mean '--enable-pre'?
next:4 X~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error: no match found
>>>>>>I'm going to investigate further tomorrow.
Ok, I don't think this failure is due to my changes but I've proposed a solution as D82001 anyway.
I'm afraid I don't really understand how this fix works, so my questions might be silly. Thanks for fixing things!
| clang-tools-extra/clangd/CMakeLists.txt | ||
|---|---|---|
| 105 | This has split our link dependencies in two, and I'm not really sure why (and so am likely to put future dependencies in the wrong place). Can *all* the link dependencies be moved to the clang_target_link_libraries section? | |
| clang-tools-extra/clangd/unittests/CMakeLists.txt | ||
| 123 | why this change? We do depend directly on LLVMSupport, and I'd prefer that to remain explicit rather than pick it up transitively. | |
| clang-tools-extra/clangd/CMakeLists.txt | ||
|---|---|---|
| 105 | No. clang_target_link_libraries is only for libraries that are included in libclang-cpp.so, so when the latter is built, they are replaced with it entirely. I'm all for improving this (e.g. to automatically replace only these libs that are included in clang-cpp) but I don't really have time to work on this beyond fixing immediate failures. | |
| clang-tools-extra/clangd/unittests/CMakeLists.txt | ||
| 123 | It's already listed in LLVM_LINK_COMPONENTS which handles using libLLVM correctly. Listing it here results in another copy of LLVMSupport being linked in which caused the test to crash immediately on duplicate command-line options. | |
Thanks! I understand the clangd stuff better now, and scanning through the other changes they seem to be the same pattern. LGTM
| clang-tools-extra/clangd/CMakeLists.txt | ||
|---|---|---|
| 105 | ah, thanks. Sounds like it should be target_link_clang_libraries then :-) | |
| clang-tools-extra/clangd/unittests/CMakeLists.txt | ||
| 123 | Thanks, sounds like we should move TestingSupport there too (but will do that separately). | |
This has split our link dependencies in two, and I'm not really sure why (and so am likely to put future dependencies in the wrong place).
Can *all* the link dependencies be moved to the clang_target_link_libraries section?
((Even if this addresses a problem only seen with clang libs, I'd rather have everything in one place)