| commit | dc73414d4ae4551f26586d57ef56355e9de95105 | [log] [tgz] |
|---|---|---|
| author | Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> | Mon Aug 03 11:24:15 2020 -0700 |
| committer | Copybara-Service <copybara-worker@google.com> | Thu Oct 29 19:21:23 2020 -0700 |
| tree | cfeaf7fde2200a747698963c5a801018c3157c4f | |
| parent | 4c2403a2c7c8cd0a172dbcccefa9e4ee5df92ffa [diff] |
[RFC] Factor out repetitive cmake patterns for llvm-style projects New projects (particularly out of tree) have a tendency to hijack the existing llvm configuration options and build targets (add_llvm_library, add_llvm_tool). This can lead to some confusion. 1) When querying a configuration variable, do we care about how LLVM was configured, or how these options were configured for the out of tree project? 2) LLVM has lots of defaults, which are easy to miss (e.g. LLVM_BUILD_TOOLS=ON). These options all need to be duplicated in the CMakeLists.txt for the project. In addition, with LLVM Incubators coming online, we need better ways for these incubators to do things the "LLVM way" without alot of futzing. Ideally, this would happen in a way that eases importing into the LLVM monorepo when projects mature. This patch creates some generic infrastructure in llvm/cmake/modules and refactors MLIR to use this infrastructure. This should expand to include add_xxx_library, which is by far the most complicated bit of building a project correctly, since it has to deal with lots of shared library configuration bits. (MLIR currently hijacks the LLVM infrastructure for building libMLIR.so, so this needs to get refactored anyway.) Differential Revision: https://reviews.llvm.org/D85140 GitOrigin-RevId: e9b87f43bde8b5f0d8a79c5884fdce639b12e0ca
See https://mlir.llvm.org/ for more information.