We are pleased to announce that Conan 1.44 has been released and brings some significant
new features and bug fixes. We added a
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
the capability of applying several user toolchains. Finally,
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"
build_requires attribute will still work in Conan 1.X, it will disappear in
Conan 2.0 so please start migrating your
to make them ready for 2.0.
New tools to explicitly handle symlinks
There are several new
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
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
is now prepared to apply several user toolchains. For example, you could have multiple
tool_requires each one defining a toolchain in its
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
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.