You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a last-mile problem for CMake. Some packages provide CMake modules with some customization that doesn't fit the general conventions and we cannot keep adding more complexity to the cpp_info model:
...there are many details hidden in other packages
If we really want to provide transparent integration, this last-mile details cannot be supported in the cpp_info, but they can be added to the build_modules, those files are included for all the CMake generates and they can populate other variables based on the value of existing ones and they could create custom targets (or alias)...
To be able to implement this feature, some work/research to be done:
include build_modules after creating the targets for cmake_find_package[_multi] generators.
build_modules need to know the generator used, so they know if targets are available or not (depending on the generator, or even depending on the TARGET argument to conan_basic_setup).
The text was updated successfully, but these errors were encountered:
Duplicated: #7261
This is a last-mile problem for CMake. Some packages provide CMake modules with some customization that doesn't fit the general conventions and we cannot keep adding more complexity to the
cpp_info
model:OpenSSL
has a different casing for the filename and the variables provided by it: https://cmake.org/cmake/help/v3.6/module/FindOpenSSL.htmlcereal
provides acereal-config.cmake
that offers targets without namespace ([package] cereal/1.3.0: cereal cannot be found when using thecmake_paths
generator conan-center-index#2151),SPIRV-tools
too (IIRC).If we really want to provide transparent integration, this last-mile details cannot be supported in the
cpp_info
, but they can be added to thebuild_modules
, those files are included for all the CMake generates and they can populate other variables based on the value of existing ones and they could create custom targets (or alias)...To be able to implement this feature, some work/research to be done:
build_modules
after creating the targets forcmake_find_package[_multi]
generators.build_modules
need to know the generator used, so they know if targets are available or not (depending on the generator, or even depending on theTARGET
argument toconan_basic_setup
).The text was updated successfully, but these errors were encountered: