llvm dev - Jan 2020 - llvm-runtimes and find_package(LLVM ...)

Some background:

When enabling runtimes, LLVM will include the runtimes directory, which will
create an external project, 'runtimes', utilizing the same CMakeLists
with a separate code path which sets up the actual build for each runtime and
for each registered target.

Each registered target is allowed to set its cmake variables in a pre-included
cache file by setting 'RUNTIMES_<target>_<variable>', which
get passed down to the runtimes build for <target>.

In the runtimes build cmake code path, an early call to find_package for LLVM
finds the generated LLVMConfig.cmake file in the build directory, which is
filled with the just-built LLVM toolchain's configurations. Among these
configurations, I believe runtimes' CMakeLists directly utilizes:

*         LLVM_LIBRARY_DIR

*         LLVM_TOOLS_BINARY_DIR

*         LLVM_BUILD_MAIN_SRC_DIR

There are a number of includes and add_subdirectory commands which also inherit
the variables imported from LLVMConfig.cmake. Specific among these is
LLVM_ENABLE_PIC, which determines if the just-built toolchain uses -fPIC.

Our issue:

My team is attempting switch from standalone builds to the runtimes system as it
seems to be the most probable standard method to build these libraries in the
future. Our libraries, however, are all being built with -fPIC, even when
RUNTIMES_<target>_LLVM_ENABLE_PIC is OFF. This is because of the
aforementioned behavior of find_package.

If I change LLVM_ENABLE_PIC manually in the LLVMConfig.cmake file, the libraries
do build without -fPIC, as expected. However, I think it's incorrect to
conflate build properties of the just-built compiler with those of the runtimes,
and a fix shouldn't require a manual modification of the config file.

This is probably a larger issue than just LLVM_ENABLE_PIC. I do have some
options, hacky or not, and will probably implement one as a temporary workaround
on our end:

*         Reinforce the command line variables after find_package to ensure that
the user's cache configurations take precedence

o   This is something like storing off all cmake variables into a known
namespace prior to find_package, and then re-iterating and setting them again
after find_package. I'm not so big a fan of this approach.

*         Modify LLVMConfig such that it does not override already-defined
variables

o   Setting something like "LLVM_CONFIG_NO_OVERRIDE" in the
runtimes' CMakeLists is visible  to LLVMConfig, and so we can utilize that
fact to perform different behavior

If one or both of these sounds somewhat reasonable, I'd be amenable to
working on and producing a patch. If neither do, then I encourage a dialogue
about what can and can't be done about this.

JB
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200109/f8ac332e/attachment-0001.html>