In my downstream LLVM passplugin project, I have something like this in the build system:
which actually works.
Until another projects that uses the
# Create imported target MYLIB
add_library(MYLIB STATIC IMPORTED)
then the project’s configuration stage errored out with:
The link interface of target "MYLIB" contains:
but the target was not found. Possible reasons include:
* There is a typo in the target name.
* A find_package call is missing for an IMPORTED target.
* An ALIAS target is missing.
I know one of the workarounds would be manually setup the cmake so that stuff like INTERFACE_INCLUDE_DIRS and INTERFACE_LINK_LIBRARIES points to the absolute path on disk.
but I feel like this is very wrong and not portable at all. Yet I cant figure out the way to inject code into LLVMExports.cmake prior to the
LLVMExports.cmake is generated by CMake, and I don’t know if there’s any way to customize it like that. You could modify https://github.com/llvm/llvm-project/blob/main/llvm/cmake/modules/LLVMConfig.cmake.in (which will include the exports) though.
ty,that solution is in my head but that kinda break the current “plug-and-play” buildsystem experience when working with passplugins…
I don’t think there’d be opposition to a CMake diff which added support for customizing LLVMConfig.cmake.in via a CMake variable. It’s worth putting up a PR for
yeah but how would that work though? A global string that gets prepended at the end of the configuration stage?.
Not an CMake expert
LLVMConfig.cmake.in already has variable placeholders like this one, which are set by code like this. You could just add another variable placeholder in LLVMConfig.cmake.in that’s meant to be populated by the user if they want any additions. (
configure_file is the CMake mechanism being used here, btw.)