meson: [meson|cmake] Generated cmake configs are broken
- do not work on windows
_lib_suffix
is not set correctly - are not separated by configuration making integration into vcpkg impossible …
- this means general setup must be separated and put into
-config/-target.cmake
while the configuration aware targets belong into-target-<config>.cmake
. CMake will select the configuration depending onCMAKE_BUILD_TYPE
or a set mapping
cc @mensinda
About this issue
- Original URL
- State: open
- Created 4 years ago
- Reactions: 2
- Comments: 15 (11 by maintainers)
@Neumann-A
Isn’t it so, that the generated
XXXTargets.cmake
orXXXConfig.cmake
file currently selects the subXXXTargets<BuildConfig>.cmake
file? So one solution would be, to use or generate an ownXXXConfig.cmake
file, which uses only the available config.Thanks for the detailed explanation. I was really hoping that we could somehow avoid the entire
install(EXPORT)
ecosystem…What we are currently doing is just replicating the functionality of
write_basic_package_version_file()
andconfigure_package_config_file()
(see the meson docs). Note that onlywrite_basic_package_version_file()
is fully automatic and the content of the<package>Config.cmake
is (as in CMake with thoese functions) up to the user/project. Unlike with*.pc
files, Meson doesn not offer a fully automatic way to generate CMake config files (beside the*Version.cmake
).So fixing/implementing this would require replicating the CMake
install(EXPORT)
mechanism. I have looked at the CMake code (see the links below) and this is far from trivial since there are no*.in
files that have to be configured, but all*Targets*.cmake
files are generated from scratch. Even worse, these files are non-standard and (apparently) were only designed to be generated and consumed by CMake.To support
install(EXPORT)
we would have to replicate 2k (and likely more) lines of CMake code in meson, which would be a huge implementation and maintenance burden for a non-standard and non-specified format that may or may not work in all circumstances. This would also require a new API in the CMake module (which isn’t a problem, just something that won’t magically fix all exsisting projects since this would be another opt-in for projects).Are there any other ways this configuration problem could be fixed besides replicating
install(EXPORT)
? Would using*.pc
files be an option?Some research notes of the CMake logic we would have to replicate: