[all-commits] [llvm/llvm-project] e9b87f: [RFC] Factor out repetitive cmake patterns for llv...

stephenneuendorffer via All-commits all-commits at lists.llvm.org
Sat Oct 3 17:51:04 PDT 2020


  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: e9b87f43bde8b5f0d8a79c5884fdce639b12e0ca
      https://github.com/llvm/llvm-project/commit/e9b87f43bde8b5f0d8a79c5884fdce639b12e0ca
  Author: Stephen Neuendorffer <stephen.neuendorffer at xilinx.com>
  Date:   2020-10-03 (Sat, 03 Oct 2020)

  Changed paths:
    A llvm/cmake/modules/LLVMProjectOptions.cmake
    A llvm/cmake/modules/LLVMProjectTargets.cmake
    M mlir/CMakeLists.txt
    M mlir/cmake/modules/AddMLIR.cmake
    M mlir/examples/standalone/CMakeLists.txt
    M mlir/examples/standalone/standalone-opt/CMakeLists.txt
    M mlir/examples/standalone/standalone-translate/CMakeLists.txt
    M mlir/examples/toy/CMakeLists.txt
    M mlir/test/Examples/standalone/test.toy
    M mlir/tools/mlir-cpu-runner/CMakeLists.txt
    M mlir/tools/mlir-cuda-runner/CMakeLists.txt
    M mlir/tools/mlir-linalg-ods-gen/CMakeLists.txt
    M mlir/tools/mlir-opt/CMakeLists.txt
    M mlir/tools/mlir-reduce/CMakeLists.txt
    M mlir/tools/mlir-rocm-runner/CMakeLists.txt
    M mlir/tools/mlir-translate/CMakeLists.txt
    M mlir/tools/mlir-vulkan-runner/CMakeLists.txt

  Log Message:
  -----------
  [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




More information about the All-commits mailing list