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 on CMAKE_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)

Most upvoted comments

@Neumann-A

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 on CMAKE_BUILD_TYPE or a set mapping

Isn’t it so, that the generated XXXTargets.cmake or XXXConfig.cmake file currently selects the sub XXXTargets<BuildConfig>.cmake file? So one solution would be, to use or generate an own XXXConfig.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() and configure_package_config_file() (see the meson docs). Note that only write_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: