meson: [meson|cmake] Generated cmake configs are broken
- do not work on windows
_lib_suffixis 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.cmakewhile the configuration aware targets belong into-target-<config>.cmake. CMake will select the configuration depending onCMAKE_BUILD_TYPEor 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.cmakeorXXXConfig.cmakefile currently selects the subXXXTargets<BuildConfig>.cmakefile? So one solution would be, to use or generate an ownXXXConfig.cmakefile, 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.cmakeis (as in CMake with thoese functions) up to the user/project. Unlike with*.pcfiles, 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*.infiles that have to be configured, but all*Targets*.cmakefiles 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*.pcfiles be an option?Some research notes of the CMake logic we would have to replicate: