Stephen Neuendorffer via llvm-dev
2020-Mar-31 00:53 UTC
[llvm-dev] llvm-lit and cmake and out-of-tree builds.
(Abandon all hope, ye who enter here?) I've been looking at better support for out-of-tree dialects in mlir. One of the natural things that we'd like to do is have llvm-lit tests for the dialects. Unfortunately, attempting to support seems non-trivial because there's a huge amount of configuration code duplicated between clang/libcxx/lld/libunwind to retrieve information in out-of-tree builds. This code is often slightly different and large amounts of the code is deprecated (1) related to using llvm-config. It's also very complicated since it has to deal with many cases (including using build areas, install areas, windows, pulling lit.py from some random source tree, and packaged lit installs to name a few). It seems to me that the right thing to do is to pass this information from LLVMConfig.cmake so that it is not rebuilt in every subproject (and in fact a simple patch to do this solves *my* problem (2)), however I fear adding yet another mechanism to this large amount of legacy. Are there thoughts on how much this is ready for general refactoring? I fear that making any progress in this is going to take significant input from a number of people across different sub-projects which certainly have different use cases. Is it time to start simplifying this code by removing use of llvm-config and relying solely on LLVMConfig.cmake? 1) https://reviews.llvm.org/D51714 2) https://reviews.llvm.org/D77110 Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200330/8c7de32f/attachment-0001.html>
Tom Stellard via llvm-dev
2020-Mar-31 15:31 UTC
[llvm-dev] llvm-lit and cmake and out-of-tree builds.
On 03/30/2020 05:53 PM, Stephen Neuendorffer wrote:> (Abandon all hope, ye who enter here?) > > I've been looking at better support for out-of-tree dialects in mlir. One of the natural things that we'd like to do is have llvm-lit tests for the dialects. Unfortunately, attempting to support seems non-trivial because there's a huge amount of configuration code duplicated between clang/libcxx/lld/libunwind to retrieve information in out-of-tree builds. This code is often slightly different and large amounts of the code is deprecated (1) related to using llvm-config. It's also very complicated since it has to deal with many cases (including using build areas, install areas, windows, pulling lit.py from some random source tree, and packaged lit installs to name a few). > > It seems to me that the right thing to do is to pass this information from LLVMConfig.cmake so that it is not rebuilt in every subproject (and in fact a simple patch to do this solves *my* problem (2)), however I fear adding yet another mechanism to this large amount of legacy. Are there thoughts on how much this is ready for general refactoring? I fear that making any progress in this is going to take significant input from a number of people across different sub-projects which certainly have different use cases. Is it time to start simplifying this code by removing use of llvm-config and relying solely on LLVMConfig.cmake? >I wrote patch #1, so this may not be a surprise, but I am in favor of removing the use of llvm-config within the sub-projects. It's much cleaner and more simple to just use the CMake files. -Tom> 1) https://reviews.llvm.org/D51714 > 2) https://reviews.llvm.org/D77110 > > Steve