History

John Ericson 44e3365775 [CMake] Factor out config prefix finding logic See the docs in the new function for details. I think I found every instance of this copy pasted code. Polly could also use it, but currently does something different, so I will save the behavior change for a future revision. We get the shared, non-installed CMake modules following the pattern established in D116472. It might be good to have LLD and Flang also use this, but that would be a functional change and so I leave it as future work. Reviewed By: beanz, lebedev.ri Differential Revision: https://reviews.llvm.org/D116521	2022-01-07 20:16:18 +00:00
..
Modules	[CMake] Factor out config prefix finding logic	2022-01-07 20:16:18 +00:00
README.md	[cmake] Add read-me for the common CMake utils	2022-01-07 20:14:32 +00:00

John Ericson 44e3365775 [CMake] Factor out config prefix finding logic

See the docs in the new function for details.

 I think I found every instance of this copy pasted code. Polly could
 also use it, but currently does something different, so I will save the
 behavior change for a future revision.

We get the shared, non-installed CMake modules following the pattern
established in D116472.

It might be good to have LLD and Flang also use this, but that would be
a functional change and so I leave it as future work.

Reviewed By: beanz, lebedev.ri

Differential Revision: https://reviews.llvm.org/D116521

2022-01-07 20:16:18 +00:00

Modules

[CMake] Factor out config prefix finding logic

2022-01-07 20:16:18 +00:00

README.md

[cmake] Add read-me for the common CMake utils

2022-01-07 20:14:32 +00:00

README.md

LLVM Common CMake Utils

What goes here

These are CMake modules to be shared between LLVM projects strictly at build time. In other words, they must not be included from an installed CMake module, such as the Add*.cmake ones. Modules that are reachable from installed modules should instead go in ${project}/cmake/modules of the most upstream project that use them.

The advantage of not putting these modules in an existing location like llvm/cmake/modules is two-fold:

Since they are not installed, we don't have to worry about any out-of-tree downstream usage, and thus there is no need for stability.
Since they are available as part of the source at build-time, we don't have to do the usual stand-alone vs combined-build dances, avoiding much complexity.

How to use

For tools, please do:

if(NOT DEFINED LLVM_COMMON_CMAKE_UTILS)
  set(LLVM_COMMON_CMAKE_UTILS ${LLVM_COMMON_CMAKE_UTILS}/../cmake)
endif()

# Add path for custom modules.
list(INSERT CMAKE_MODULE_PATH 0
  # project-specific module dirs first
  "${LLVM_COMMON_CMAKE_UTILS}/Modules"
  )

The if(NOT DEFINED ...) guard is there because in combined builds, LLVM will set this variable. This is useful for legacy builds where projects are found in llvm/tools instead.
INSERT ... 0 ensures these new entries are prepended to the front of the module path, so nothing might shadow them by mistake.

If runtime libs, we skip the if(NOT DEFINED part:

set(LLVM_COMMON_CMAKE_UTILS ${LLVM_COMMON_CMAKE_UTILS}/../cmake)

... # same as before

If llvm/tools legacy-style combined builds are deprecated, we should then skip it everywhere, bringing the tools and runtimes boilerplate back in line.