[flang] Fix finding system install of LLVM/Clang/MLIR in standalone builds #120914
Conversation
…uilds The changes in llvm#87822 introduced a regression where Flang could no longer be built standalone without explicitly specifying all of LLVM_DIR, CLANG_DIR and MLIR_DIR. Restore the earlier logic that used these paths as hints, and supported finding system-wide LLVM install via default paths. Instead, make paths absolute after locating the packages, using the paths CMake determined.
|
Thanks! |
|
This broke flang-aarch64-out-of-tree: https://lab.llvm.org/buildbot/#/builders/53/builds/10501. For some reason the commit doesn't appear in the changes tab, but I reproduced it locally and was to build flang standalone again when reverting this change. |
This is a known issue with that bot, I never did figure out why it does that. Perhaps it triggers on changes to anything other than Flang, so it only lists those. |
|
Now I'm confused. https://lab.llvm.org/buildbot/#/builders/53/builds/10577 seems to be building, yet I don't see any relevant changes? |
The failure happens in step 6. It first builds llvm, clang and mlir, and then the standalone flang. |
|
Ah, sorry. Reverted now. |
This change should be related: llvm/llvm-zorg#170 Sorry, it was long time ago, so I forgot about it. |
|
I don't really want to break anyone's use cases, so I'm going to prepare a less intrusive patch tomorrow. |
…uilds (llvm#120914) The changes in llvm#87822 introduced a regression where Flang could no longer be built standalone without explicitly specifying all of LLVM_DIR, CLANG_DIR and MLIR_DIR. Restore the earlier logic that used these paths as hints, and supported finding system-wide LLVM install via default paths. Instead, make paths absolute after locating the packages, using the paths CMake determined. ----- @vzakhari, could you confirm that this doesn't break your use case?
…dalone builds (llvm#120914)" This reverts commit 8e12037. It broke the flang-aarch64-out-of-tree buildbot.
Support discovering LLVM, Clang and MLIR via the standard CMake logic in addition to explicitly specified `LLVM_DIR`, etc. To prevent breaking anyone's workflow the way llvm#120914 did, this change explicitly introduces two possible code paths based on variables provided: 1. If `LLVM_DIR`, etc. are defined, the current logic is used as-is. 2. If they are not defined, `find_package()` is called normally to discover the packages using the standard CMake logic, and the discovered paths are added
…122639) Support discovering LLVM, Clang and MLIR via the standard CMake logic in addition to explicitly specified `LLVM_DIR`, etc. To prevent breaking anyone's workflow the way #120914 did, this change explicitly introduces two possible code paths based on variables provided: 1. If `LLVM_DIR`, etc. are defined, the current logic is used as-is. 2. If they are not defined, `find_package()` is called normally to discover the packages using the standard CMake logic, and the discovered paths are added --------- Co-authored-by: Slava Zakharin <[email protected]>
…lvm#122639) Support discovering LLVM, Clang and MLIR via the standard CMake logic in addition to explicitly specified `LLVM_DIR`, etc. To prevent breaking anyone's workflow the way llvm#120914 did, this change explicitly introduces two possible code paths based on variables provided: 1. If `LLVM_DIR`, etc. are defined, the current logic is used as-is. 2. If they are not defined, `find_package()` is called normally to discover the packages using the standard CMake logic, and the discovered paths are added --------- Co-authored-by: Slava Zakharin <[email protected]>
The changes in #87822 introduced a regression where Flang could no longer be built standalone without explicitly specifying all of LLVM_DIR, CLANG_DIR and MLIR_DIR. Restore the earlier logic that used these paths as hints, and supported finding system-wide LLVM install via default paths. Instead, make paths absolute after locating the packages, using the paths CMake determined.
@vzakhari, could you confirm that this doesn't break your use case?