Conan 1.30 has been released. This release moves forward on several integrations including GCC, Intel compiler, and MSBuild. It brings some more maturity around components, and adds a new way to use custom generators. Also, macOS 11 (aka “Big Sur”) has now been added to Conan’s default settings.
Improved libcxx detection for GCC
When Conan is installed, it autodetects a number of settings based on the
environment. Among those settings are
gcc, it also detects
compiler.libcxx which has had some
challenging corner cases for a while. This release adds robustness to the
libcxx detection which hopefully will result in better defaults for those
corner cases when Conan is installed.
Note: If we enabled this behavior by default, it could be considered a breaking
change, so we had to leave it off by default and users must set the
to turn it on.
Experimental tools for intel compiler support
Conan’s tools module
conanfile.py authors with a number of helper functions to
reduce boilerplate code in recipes and avoid common errors. Three new functions
have now been exposed for when recipes need special handling to work with the
Experimental Toolchain for MSBuild
Continuing our work on Conan’s new toolchain strategy, this release contains a
toolchain class for the
MSBuild build system. Like the existing
Make toolchains which have been added previously, this new toolchain class
.props files which contain all the relevant build-related variables
from Conan. These
.props files do NOT include variables related to
dependencies. Dependency-related information should still be generated by the
New self.cpp_info.requires attribute
We have also continued to evolve and improve the experience around the
components feature. A common case that has come up is that many packages which
declare components are depended upon by downstream packages which do not declare
components. Previously, when the downstream package only depends upon specific
components of the upstream package, it could not model that in it’s own
cpp_info. This meant that all transitive consumers would end up depending on
all components of the original upstream.
This is a tricky problem to describe without an example, so here is the example
package_info method from the OpenSSL recipe, and one from a consumer of
# Conanfile for OpenSSL: def package_info(self): self.cpp_info.name = "OpenSSL" self.cpp_info.components["crypto"].names["cmake_find_package"] = "Crypto" self.cpp_info.components["crypto"].libs = ["libcrypto"] self.cpp_info.components["crypto"].defines = ["DEFINE_CRYPTO=1"] self.cpp_info.components["crypto"].requires = ["zlib::zlib"] self.cpp_info.components["ssl"].names["cmake"] = "SSL" self.cpp_info.components["ssl"].includedirs = ["include/headers_ssl"] self.cpp_info.components["ssl"].libs = ["libssl"]
# Conanfile for consumer of OpenSSL: def package_info(self): self.cpp_info.requires = ['openssl::ssl'] # Depends only on ssl component # Which notably does NOT depend on zlib # ...
OpenSSL declares two components:
crypto. The consumer package only
needs one of them (
ssl). With the new
cpp_info.requires attribute, the
consumer can properly declare that dependency. The result is that this consumer,
and all future downstream consumers of it will only link with the
component of the OpenSSL package and not
Other notable changes
The Qbs generator received a significant update which makes it properly model
transitive dependencies using the native dependency declaration syntax. This
cuts down on clutter and should enforce linker order properly. The
Markdown generators both learned how to include the
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.