We are pleased to announce that Conan 1.43 is
out and comes with some
significant new features and bug fixes. We are putting lots of effort into providing the
tools to help users to prepare their recipes for Conan 2.0. For example, we have changed
cpp_info properties model to push the migration of recipes in Conan Center, reducing
the risk of breaking consumers that use the current
Also to help preparing recipes for 2.0, we have added a new
test_requires() method to
help migrating the
force_host_context arguments in
build_requires() method. You can
also import ConanFile in recipes from the conan namespace (the only one existing for 2.0)
instead of the conans one. Besides that, there’s a new
tools.gnu.PkgConfig that replaces
tools.PkgConfig. Finally, we have a new
os setting to represent Hardware platforms
without an operating system.
Prepare your recipes for Conan 2.0
Conan 2.0-alpha2 was released this past month. We have a new section in the documentation to help users prepare their recipes in 1.X to be compatible with the Conan 2.0 syntax. If you want to give Conan 2.0 a try, you can install it using pip:
$ pip install conan==2.0.0-alpha2
Changes in cpp_info properties model
Starting in Conan 1.43, we have decided that the properties model is used only by the new
The current generators, like
cmake_find_package_multi, will not
listen to these properties. Setting that cpp_info information independent makes the
migration process less prone to error. The drawback is that we need to maintain both the
.filenames, etc. attributes and the
set_property methods coexisting in
recipes in Conan Center Index. This coexistence will end once we no longer support current
generators sometime after Conan 2.0 is released. Then, the old attributes will disappear
from recipes, and only the
set_property model will remain.
There are a couple of details that must be taken into account when introducing the new properties model in recipes:
- In contrast to the
.namesattribute, the target names set with the
cmake_target_nameproperty are “absolute”. That means that Conan will not prepend any namespaces to the value you set with this property.
- When consumers use the CMakeDeps generator, this generator will create config CMake
scripts by default. To generate CMake module files, you have to set the
cmake_find_modeproperty for this generator.
Let’s see an example of how recipes have to be modified and how they will look in this transition from Conan 1.X to 2.0.
... class AlembicConan(ConanFile): name = "alembic" ... def package_info(self): self.cpp_info.names["cmake_find_package"] = "Alembic" self.cpp_info.names["cmake_find_package_multi"] = "Alembic" ...
With the current model, the
cmake_find_package/multi generators will create the
Alembic::Alembic target. For the filename, it will inherit the value set with
AlembicConfig.cmake, etc. To set the same information
for the new
CMakeDeps generators we should add the
... class AlembicConan(ConanFile): name = "alembic" ... def package_info(self): self.cpp_info.names["cmake_find_package"] = "Alembic" self.cpp_info.names["cmake_find_package_multi"] = "Alembic" self.cpp_info.set_property("cmake_target_name", "Alembic::Alembic") self.cpp_info.set_property("cmake_file_name", "Alembic") ...
Please, check the docs for a detailed guide on how set the properties in your recipes to prepare them for Conan 2.0.
Use test_requires instead of force_host_context
We have added a
self.test_requires() method to recipes meant to substitute the
force_host_context argument from the
self.build_requires() method. This is the way
that build requirements in the
are set for Conan 2.0. Please update your recipes to the new syntax:
from conan import ConanFile class App(ConanFile): name = "app" version = "1.0" def build_requirements(self): self.test_requires("gtest/1.11.0")
Please, note another syntax change in the recipe above. Now you can do import ConanFile
from conan import ConanFile
import instead of the legacy
from conans ... (note the plural).
Conan 1.43 brings the new
tool, that improves and replaces the current
This tool can extract information from existing from existing
This can be used, for example, to create a “system” package recipe over some system
installed library, as a way to automatically extract the
.pc information from the system.
Or if some proprietary package has a build system that only outputs
This tool provides a
fill_cpp_info() method that can be used in the
method to translate the information from the
.pc files to the Conan
see an example:
... class MyPkg(ConanFile): ... def package_info(self): pkg_config = PkgConfig(self, "gl") pkg_config.fill_cpp_info(self.cpp_info, is_system=True) ...
This will get the information from the
gl.pc file and translate that to the attributes
cpp_info. In this case, for example, it will add
self.cpp_info.system_libs. Please, check the Conan documentation for more details on the
New baremetal os setting for Hardware platforms without operating system
Conan 1.43 comes with a new
baremetal os setting added to the default Conan settings.
This setting is just a general name convention and it is expected that users might
customize the space inside the
baremetal setting with further subsettings to specify
their specific hardware platforms, boards, families, etc.
os=baremetal value is still not used by Conan builtin toolchains and helpers, but
it is expected that, as the evolve, they start using it in the future.
Besides the items listed above, there were some minor bug fixes you may wish to read about. If so, please refer to the changelog for the complete list.
We hope you enjoy this release, and look forward to your feedback.