Conan 1.40 brings several significant new features. We have improved CMakeDeps and CMakeToolchain helpers adding new properties that make them more flexible. Also, finally, we have removed the old conan-center remote and added the new conancenter as the only predefined remote. We have added support for Clang 13 and Visual Studio 2022. Also, now setting default_build_profile in global.conf you can define the profile that Conan uses by default in the build context.

Conan 1.40 marks an important milestone: Starting transition to new features

Before going through the new features in Conan 1.40, we would like to mention how important this new Conan version is. We consider some new experimental features like the two profiles approach or the new conan.tools stable enough to be used in Conan Center Index. As soon as the Conan Center Index infrastructure is updated, the migration to these new features will begin. Also, we have already updated the “Creating Packages: Getting Started” section of the documentation to use these new tools.

It is a huge step forward in the transition to Conan 2.0. We remind you that all these toolchains and helpers related to different build systems, the environment, and the layout of the packages will be the only ones remaining for the 2.0 version. If you want a smooth transition to the new major version, we advise you to start testing them with the 1.X versions.

Soon, we will give more details on the transition in Conan Center. Also, if you want to stay updated on the new developments and proposals for Conan 2.0, please check the Conan 2.0 tribe repository.

Improvements in CMakeDeps and CMakeToolchain helpers

We have added some new properties in the new CMake helpers to make them more flexible. Let’s go through some of them:

  • cmake_target_namespace: Use it to set the namespace of the target consumed in CMake. By default, this namespace is the same as the library name or to the value of the cmake_target_name property. So, if you create a library named hello, the default target to link in the consumer will be hello::hello. With this property, we can customize that target namespace to others like MyChat::.

Set this property in the package_info of the recipe:

class HelloConan(ConanFile):
    name = "hello"
    version = "0.1"
    ...
    def package_info(self):
        self.cpp_info.set_property("cmake_target_namespace", "MyChat")
    ...

Then, the consumer of the library can link the library using the new namespace in the CMakeLists.txt.

cmake_minimum_required(VERSION 3.15)
project(Consumer CXX)
find_package(hello CONFIG REQUIRED)
add_executable(example example.cpp)
target_link_libraries(example MyChat::hello)

  • cmake_find_mode: Use it to make CMakeDeps generate FindXXX.cmake module files, config CMake scripts, both of them or none. It can take the values: module, config, both and none. The none option can be convenient if you want to make a package that wraps system libraries, and the consumers should find the config files in the CMake config path.

  • cmake_module_file_name, cmake_module_target_name, cmake_module_target_namespace: These properties are equivalent to cmake_file_name, cmake_target_name and cmake_target_namespace but will be used for FindXXX.cmake module files when cmake_find_mode is module or both.

Setting conancenter (center.conan.io) as the only predefined Conan remote

As you probably know, we released a new remote for ConanCenter in May with a more resilient and scalable architecture. It’s been the default since Conan 1.37, and now in the 1.40 version, we have removed the old bintray remote and left https://center.conan.io as the only predefined remote for Conan. If you are using an older Conan version, remember that the old remote is frozen and that new packages are only available via the new https://center.conan.io. For more information about this, read the dedicated blog entry.

Support for Clang 13 and Visual Studio 2022

Although Clang 13 and Visual Studio 2022 are not officially released yet, we have added support for them in this release in case users want to start testing them. Please note that this support is considered experimental, so it may change when the official versions are released.

Use default_build_profile to set a default build context profile

Now you can set a default profile for the profile build that Conan uses for several commands. Also, a host profile can be set as default as well. Using this is as easy as setting core:default_build_profile and core:default_profile in the global.conf configuration file. Imagine that we want to always compile for a Linux arm device in our MacOs development environment:

core:default_build_profile=macos_profile
core:default_profile=linux_armv8_profile

Please, note that Conan 2.0 will always use these defaults, so defining them while using 1.X will help transition to the 2.0 version. If you want to read more about this change for 2.0, please check the accepted proposal in the Conan 2.0 tribe repository.


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.