- #Cmake install component install
- #Cmake install component generator
# Foo::Var target name for the component "mycomponent" set_property ( "cmake_target_name", "Foo" ) # self.cpp_t_property("cmake_target_namespace", "Foo") # This can be omitted as the value is the same set_property ( "cmake_file_name", "MyFileName" ) # Foo:: namespace for the targets (Foo::Foo if no components)
#Cmake install component install
This file is saved after a conan install based on the settings and options and can be used like any other CMake toolchain:ĭef package_info ( self ).
#Cmake install component generator
The CMakeToolchain generator to create a conan_toolchain.cmake. To help resolve this missing piece we introduced two new generators: We wanted to have the same user experience and results when building a CMake project no matter if doing a conan create, or developing a library calling “cmake” in the command line, or clicking a “build” button in the IDE. We had so many CMake integrations but we felt like we were missing something. Too many CMake integrations, right? A New Approach That’s why we created the cmake_find_package_multi, based on targets, config files instead of modules, and it was able to support multi-configuration projects, using generator expressions.įinally, we created the cmake_paths generator to point the CMAKE_PREFIX_PATH and CMAKE_MODULE_PATH to the packages, in order to support people packaging modules and config cmake files in the Conan packages. The “target approach” assumed that global variables should not be used, and all the information about a library or executable should be associated with a “target.” Soon, a new concept called “modern CMake” was raised. Conan generates different FindXXX.cmake modules for each dependency, so you could call find_package(XXX) and a bunch of variables were set, so you could link with your requirements. The usage of find_package() in the CMake community was getting popular, so we created the cmake_find_package generator. Later the cmake_multi generator gave support to multi-config projects like Visual Studio creating different conanbuildinfo.cmake files for Release or Debug. 
The way to consume Conan packages with the cmake generator was including a conanbuildinfo.cmake file and calling a conan_basic_setup() macro that adjusted the necessary CMake global variables to locate the include directories, the libraries to link with, and so on. We created the first cmake generator to address this issue. A Bit of History…īack in the day when Conan was first created the CMake approach was based on “global variables.” The concepts of “modern CMake” and “Targets” didn’t exist or were very uncommon. In the near future these new generators will be introduced in the conan-center-index. Building on this evolution we are pleased to present a new unified way to create Conan packages with CMake. The CMake ecosystem and Conan have continually evolved since their conception.
0 kommentar(er)
