[llvm-dev] llvm-runtimes and find_package(LLVM ...)

[Nagurne, James via llvm-dev]

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>