We’re experimenting with making a large project (Qt) generate CPS files with install(PACKAGE_INFO), alongside the usual Qt6*Config.cmake package files, using CMake 4.4.3.
Our main problem is generator expressions in interface properties.
Some usage requirements are stored as generator expressions, for example -fPIC for every language except Swift:
target_compile_options(foo INTERFACE "$<$<NOT:$<COMPILE_LANGUAGE:Swift>>:-fPIC>")
The CPS exporter stops with a fatal error on these:
CMake Error in CMakeLists.txt:
Property "INTERFACE_COMPILE_OPTIONS" of target "foo" contains a generator
expression. This is not allowed.
Minimal reproducer (CMake 4.3 or 4.4):
cmake_minimum_required(VERSION 3.31)
project(Repro VERSION 1.0.0 LANGUAGES CXX)
add_library(foo foo.cpp)
target_compile_options(foo INTERFACE "$<$<NOT:$<COMPILE_LANGUAGE:Swift>>:-fPIC>")
install(TARGETS foo EXPORT repro ARCHIVE DESTINATION lib)
install(EXPORT repro DESTINATION lib/cmake/Repro NAMESPACE Repro:: FILE ReproTargets.cmake)
install(PACKAGE_INFO Repro EXPORT repro DESTINATION lib/cps) # fails here
Clearly, these cannot go into a portable CPS file, and that is fine. Our trouble is that to make the CPS export pass, we have to remove the entry from the target, and then the normal install(EXPORT) / Qt6*Config.cmake export loses it too, because both read the same target at generate time. So we cannot produce good CPS files and full CMake config files from one build.
We could not find a way to give the CPS export a reduced set of interface properties while the CMake config export keeps the full set.
Question 1: what is the recommended way today to give the CPS export a reduced set of interface properties while the CMake config export keeps the full set, from one build? If there is none, would a per-export override be something you would consider, for example the CPS exporter preferring a CPS_<PROPERTY> value when it is set?
We also have a smaller question about external dependencies. We checked and it works well when a dependency is found in CONFIG mode and its target namespace matches the package name: CMake writes a proper requires (with a hints path) and a CPS consumer resolves it via a nested find_package, even if that dependency ships no CPS itself. The cases we are unsure about are dependencies that only come from a Find module (for example Threads::Threads from FindThreads, with no ThreadsConfig.cmake). A CPS requires on those cannot be resolved by a consumer.
Question 2: how should a package express a dependency that is only provided by a Find module, with no config package? Should it become a raw entry in link_libraries, or is there another intended mechanism?