We are pleased to announce that Conan 1.44 has been released and brings some significant new features and bug fixes. We added a tool_requires attribute to provide a compatible way to migrate to Conan 2.0. Also, this version comes with several functions under conan.tools.files.symlinks to help manage symlinks. We have also added to CMakeToolchain the capability of applying several user toolchains. Finally, CMakeDeps adds several variables to match upstream CMake modules as much as possible.

New tool_requires attribute

Starting in Conan 1.44, we renamed “build requirement” to “tool requirement”. The purpose of this is to highlight that the usage of this kind of requirement must be for “tools” exclusively, not being valid for libraries to express a “private” requirement or other meanings. Now recipes will look like this:

class MyPkg(ConanFile):
    tool_requires = "cmake/3.19.6"

Although the build_requires attribute will still work in Conan 1.X, it will disappear in Conan 2.0 so please start migrating your recipes to make them ready for 2.0.

There are several new functions under conan.tools.files.symlinks to manage symlinks. With these tools, you can transform absolute to relative symlinks, remove broken symlinks, remove external symlinks and get the symlinks in a folder. Bear in mind that Conan 2.0 will not handle packages symlinks automatically. These tools are handy to migrate recipes and make them work as expected in 2.0.

Let’s have a look at them:

  • Convert the symlinks with absolute paths into relative ones. It will only consider those inside the ‘base_folder’.
def absolute_to_relative_symlinks(conanfile, base_folder):
  • Remove external symlinks to files that point outside the ‘base_folder’, no matter if relative or absolute.
def remove_external_symlinks(conanfile, base_folder):
  • Remove broken symlinks, no matter if relative or absolute.
def remove_broken_symlinks(conanfile, base_folder):

Apply multiple user toolchains with CMakeToolchain

The CMakeToolchain is now prepared to apply several user toolchains. For example, you could have multiple tool_requires each one defining a toolchain in its package_info method:

import os
from conans import ConanFile
class ToolchainPackage(ConanFile):
    name = "toolchain1"
    ...
    def package_info(self):
        f = os.path.join(self.package_folder, "mytoolchain.cmake")
        self.conf_info["tools.cmake.cmaketoolchain:user_toolchain"] = f

If you want to use several toolchains in a recipe, you can gather the values from all the dependency configs and adjust the user_toolchain block to apply all the toolchains:

from conans import ConanFile
from conan.tools.cmake import CMake, CMakeToolchain
class Pkg(ConanFile):
    ...
    tool_requires = "toolchain1/1.0", "toolchain2/1.0"
    def generate(self):
        # Get the toolchains from "tools.cmake.cmaketoolchain:user_toolchain" conf at the
        # tool_requires
        user_toolchains = []
        for dep in self.dependencies.direct_build.values():
            ut = dep.conf_info["tools.cmake.cmaketoolchain:user_toolchain"]
            if ut:
                user_toolchains.append(ut)
        # Modify the context of the user_toolchain block
        t = CMakeToolchain(self)
        t.blocks["user_toolchain"].values["paths"] = user_toolchains
        t.generate()
      ...

This way, the conan_toolchain.cmake file generated by Conan will include both toolchains before declaring anything else:

...
include("/path/to/mytoolchain.cmake")
include("/otherpath/to/mytoolchain.cmake")
...

Added variables to CMakeDeps to match better with upstream

As a way of getting closer to the typical variables declared by CMake official find modules we added these variables so they are available when using CMakeDeps Conan generator:

  • PackageName_LIBRARIES
  • PackageName_INCLUDE_DIRS
  • PackageName_INCLUDE_DIR
  • PackageName_DEFINITIONS
  • PackageName_VERSION_STRING

These definitions will certainly help in the vast majority of the cases. The intention is not to try to define every possible variable that is defined by the official modules, those should be added in recipes using a custom build_module.


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.