Attributes¶
name¶
-
ConanFile.
name
= None¶ String corresponding to the
<name>
at the recipe reference<name>/version@user/channel
A valid name has:
- A minimum of 2 and a maximum of 101 characters (though shorter names are recommended).
- Matches the following regex
^[a-z0-9_][a-z0-9_+.-]{1,100}$
: so starts with alphanumeric or_
, then from 1 to 100 characters between alphanumeric,_
,+
,.
or-
.
The name is only necessary for
export
-ing the recipe into the local cache (export
andcreate
commands), if they are not defined in the command line.
version¶
-
ConanFile.
version
= None¶ String corresponding to the
<version>
at the recipe referencename/<version>@user/channel
A valid version follows the same rules than the
name
attribute. In case the version follows semantic versioning in the formX.Y.Z-pre1+build2
, that value might be used for requiring this package through version ranges instead of exact versions.The version is only strictly necessary for
export
-ing the recipe into the local cache (export
andcreate
commands), if they are not defined in the command line.
package_type¶
-
ConanFile.
package_type
= None¶ Optional. Declaring the
package_type
will help Conan:- To choose better the default
package_id_mode
for each dependency, that is, how a change in a dependency should affect thepackage_id
to the current package. - Which information from the dependencies should be propagated to the consumers, like headers, libraries, runtime information…
The valid values are:
- application: The package is an application.
- library: The package is a generic library. It will try to determine
the type of library (from
shared-library
,static-library
,header-library
) reading theself.options.shared
(if declared) and theself.options.header_only
- shared-library: The package is a shared library.
- static-library: The package is a static library.
- header-library: The package is a header only library.
- build-scripts: The package only contains build scripts.
- python-require: The package is a python require.
- unknown: The type of the package is unknown.
- To choose better the default
description¶
-
ConanFile.
description
= None¶ Description of the package and any information that might be useful for the consumers. The first line might be used as a short description of the package.
This is an optional, but strongly recommended text field, containing the description of the package, and any information that might be useful for the consumers. The first line might be used as a short description of the package.
class HelloConan(ConanFile): name = "hello" version = "0.1" description = """This is a Hello World library. A fully featured, portable, C++ library to say Hello World in the stdout, with incredible iostreams performance"""
homepage¶
-
ConanFile.
homepage
= None¶ The home web page of the library being packaged.
Used to link the recipe to further explanations of the library itself like an overview of its features, documentation, FAQ as well as other related information.
class EigenConan(ConanFile): name = "eigen" version = "3.3.4" homepage = "http://eigen.tuxfamily.org"
url¶
-
ConanFile.
url
= None¶ URL of the package repository, i.e. not necessarily of the original source code. Recommended, but not mandatory attribute.
class HelloConan(ConanFile): name = "hello" version = "0.1" url = "https://github.com/conan-io/hello.git"
license¶
-
ConanFile.
license
= None¶ License of the target source code and binaries, i.e. the code that is being packaged, not the
conanfile.py
itself. Can contain several, comma separated licenses. It is a text string, so it can contain any text, but it is strongly recommended that recipes of Open Source projects use SPDX identifiers from the SPDX license listThis will help people wanting to automate license compatibility checks, like consumers of your package, or you if your package has Open-Source dependencies.
class HelloConan(ConanFile): name = "hello" version = "0.1" license = "MIT"
author¶
Main maintainer/responsible for the package, any format. This is an optional attribute.
class HelloConan(ConanFile): name = "hello" version = "0.1" author = "John J. Smith (john.smith@company.com)"
topics¶
-
ConanFile.
topics
= None¶ Tags to group related packages together and describe what the code is about. Used as a search filter in conan-center. Optional attribute. It should be a tuple of strings.
class ProtocInstallerConan(ConanFile): name = "protoc_installer" version = "0.1" topics = ("protocol-buffers", "protocol-compiler", "serialization", "rpc")
user, channel¶
-
ConanFile.
user
= None¶ String corresponding to the
<user>
at the recipe referencename/version@<user>/channel
A valid string for the
user
field follows the same rules than thename
attribute. This is an optional attribute. It is sometimes used to identify a forked recipe, giving a different namespace to the recipe reference.
-
ConanFile.
channel
= None¶ String corresponding to the
<channel>
at the recipe referencename/version@user/<channel>
.A valid string for the
channel
field follows the same rules than thename
attribute. This is an optional attribute. It is sometimes used to identify a maturity of the package (stable, testing…).The value of these fields can be accessed from within a
conanfile.py
:from conan import ConanFile class HelloConan(ConanFile): name = "hello" version = "0.1" def requirements(self): self.requires("common-lib/version") if self.user and self.channel: # If the recipe is using them, I want to consume my fork. self.requires("say/0.1@%s/%s" % (self.user, self.channel)) else: # otherwise, I'll consume the community one self.requires("say/0.1")
Only packages that have already been exported (packages in the local cache or in a remote server) can have a user/channel assigned. For package recipes working in the user space, there is no current user/channel by default, although they can be defined at conan install time with:
$ conan install <path to conanfile.py> --user my_user --channel my_channel
settings¶
-
ConanFile.
settings
= None¶ List of strings with the first level settings (from
settings.yml
) that the recipe need, because:- They are read for building (e.g: if self.settings.compiler == “gcc”)
- They affect the
package_id
. If a value of the declared setting changes, thepackage_id
has to be different.
The most common is to declare:
settings = "os", "compiler", "build_type", "arch"
Once the recipe is loaded by Conan, the
settings
are processed and they can be read in the recipe, also the sub-settings:settings = "os", "arch" def build(self): if self.settings.compiler == "gcc": if self.settings.compiler.cppstd == "gnu20": # do some special build commands
If you try to access some setting that doesn’t exist, like
self.settings.compiler.libcxx
for themsvc
setting, Conan will fail telling thatlibcxx
does not exist for that compiler.If you want to do a safe check of settings values, you could use the
get_safe()
method:def build(self): # Will be None if doesn't exist (not declared) arch = self.settings.get_safe("arch") # Will be None if doesn't exist (doesn't exist for the current compiler) compiler_version = self.settings.get_safe("compiler.version") # Will be the default version if the return is None build_type = self.settings.get_safe("build_type", default="Release")
The
get_safe()
method will returnNone
if that setting or sub-setting doesn’t exist and there is no default value assigned.If you want to do a safe deletion of settings, you could use the
rm_safe()
method. For example, in theconfigure()
method a typical pattern for a C library would be:def configure(self): self.settings.rm_safe("compiler.libcxx") self.settings.rm_safe("compiler.cppstd")
See also
- Removing settings in the
package_id()
method. <MISSING PAGE>
options¶
-
ConanFile.
options
= None¶ Dictionary with traits that affects only the current recipe, where the key is the option name and the value is a list of different values that the option can take. By default any value change in an option, changes the
package_id
. Check thedefault_options
field to define default values for the options.Values for each option can be typed or plain strings (
"value"
,True
,42
,…).There are two special values:
None
: Allow the option to have aNone
value (not specified) without erroring."ANY"
: For options that can take any value, not restricted to a set.
class MyPkg(ConanFile): ... options = { "shared": [True, False], "option1": ["value1", "value2"], "option2": ["ANY"], "option3": [None, "value1", "value2"], "option4": [True, False, "value"], }
Once the recipe is loaded by Conan, the
options
are processed and they can be read in the recipe. You can also use the method.get_safe()
(see settings attribute) to avoid Conan raising an Exception if the option doesn’t exist:class MyPkg(ConanFile): options = {"shared": [True, False]} def build(self): if self.options.shared: # build the shared library if self.options.get_safe("foo", True): pass
In boolean expressions, like
if self.options.shared
:- equals
True
for the valuesTrue
,"True"
and"true"
, and any other value that would be evaluated the same way in Python code. - equals
False
for the valuesFalse
,"False"
and"false"
, also for the empty string and for0
and"0"
as expected.
Notice that a comparison using
is
is alwaysFalse
because the types would be different as it is encapsulated inside a Python class.If you want to do a safe deletion of options, you could use the
rm_safe()
method. For example, in theconfig_options()
method a typical pattern for Windows library would be:def config_options(self): if self.settings.os == "Windows": self.options.rm_safe("fPIC")
See also
- Read the Getting started, creating packages to know how to declare and how to define a value to an option.
- Removing options in the
package_id()
method. <MISSING PAGE> - About the package_type and how it plays when a
shared
option is declared. <MISSING PAGE>
default_options¶
-
ConanFile.
default_options
= None¶ The attribute
default_options
defines the default values for the options, both for the current recipe and for any requirement. This attribute should be defined as a python dictionary.class MyPkg(ConanFile): ... requires = "zlib/1.2.8", "zwave/2.0" options = {"build_tests": [True, False], "option2": "ANY"} default_options = {"build_tests": True, "option1": 42, "z*: shared": True}
You can also assign default values for options of your requirements using “<reference_pattern>: option_name”, being a valid
reference_pattern
aname/version
or any pattern with*
like the example above.You can also set the options conditionally to a final value with
configure()
instead of usingdefault_options
:class OtherPkg(ConanFile): settings = "os", "arch", "compiler", "build_type" options = {"some_option": [True, False]} # Do NOT declare 'default_options', use 'config_options()' def configure(self): if self.options.some_option == None: if self.settings.os == 'Android': self.options.some_option = True else: self.options.some_option = False
Take into account that if a value is assigned in the
configure()
method it cannot be overridden.See also
Read more about the <MISSING PAGE>method_configure_config_options method.
options_description¶
TODO: Complete, https://github.com/conan-io/conan/pull/11295
requires¶
-
ConanFile.
requires
= None¶ List or tuple of strings for regular dependencies in the host context, like a library.
class MyLibConan(ConanFile): requires = "hello/1.0", "otherlib/2.1@otheruser/testing"
You can specify version ranges, the syntax is using brackets:
class HelloConan(ConanFile): requires = "pkg/[>1.0 <1.8]"
Accepted expressions would be:
>1.1 <2.1 # In such range 2.8 # equivalent to =2.8 ~=3.0 # compatible, according to semver >1.1 || 0.8 # conditions can be OR'ed
See also
- Check <MISSING PAGE> version_ranges if you want to learn more about version ranges.
- Check <MISSING PAGE> requires() conanfile.py method.
tool_requires¶
-
ConanFile.
tool_requires
= None¶ List or tuple of strings for dependencies. Represents a build tool like “cmake”. If there is an existing pre-compiled binary for the current package, the binaries for the tool_require won’t be retrieved. They cannot conflict.
class MyPkg(ConanFile): tool_requires = "tool_a/0.2", "tool_b/0.2@user/testing"
This is the declarative way to add
tool_requires
. Check the <MISSING PAGE> tool_requires() conanfile.py method to learn a more flexible way to add them.
build_requires¶
-
ConanFile.
build_requires
= None¶ List or tuple of strings for dependencies. Generic type of build dependencies that are not applications (nothing runs), like build scripts. If there is an existing pre-compiled binary for the current package, the binaries for the build_require won’t be retrieved. They cannot conflict.
class MyPkg(ConanFile): build_requires = ["my_build_scripts/1.3",]
This is the declarative way to add
build_requires
. Check the <MISSING PAGE> build_requires() conanfile.py method to learn a more flexible way to add them.
test_requires¶
-
ConanFile.
test_requires
= None¶ List or tuple of strings for dependencies in the host context only. Represents a test tool like “gtest”. Used when the current package is built from sources. They don’t propagate information to the downstream consumers. If there is an existing pre-compiled binary for the current package, the binaries for the test_require won’t be retrieved. They cannot conflict.
class MyPkg(ConanFile): test_requires = "gtest/1.11.0", "other_test_tool/0.2@user/testing"
This is the declarative way to add
test_requires
. Check the <MISSING PAGE> test_requires() conanfile.py method to learn a more flexible way to add them.
exports¶
-
ConanFile.
exports
= None¶ List or tuple of strings with file names or fnmatch patterns that should be exported and stored side by side with the conanfile.py file to make the recipe work: other python files that the recipe will import, some text file with data to read,…
For example, if we have some python code that we want the recipe to use in a
helpers.py
file, and have some text file info.txt we want to read and display during the recipe evaluation we would do something like:exports = "helpers.py", "info.txt"
Exclude patterns are also possible, with the
!
prefix:exports = "*.py", "!*tmp.py"
See also
- Check <MISSING PAGE> exports() conanfile.py method.
exports_sources¶
-
ConanFile.
exports_sources
= None¶ List or tuple of strings with file names or fnmatch patterns that should be exported and will be available to generate the package. Unlike the
exports
attribute, these files shouldn’t be used by theconanfile.py
Python code, but to compile the library or generate the final package. And, due to its purpose, these files will only be retrieved if requested binaries are not available or the user forces Conan to compile from sources.This is an alternative to getting the sources with the
source()
method. Used when we are not packaging a third party library and we have together the recipe and the C/C++ project:exports_sources = "include*", "src*"
Exclude patterns are also possible, with the
!
prefix:exports_sources = "include*", "src*", "!src/build/*"
Note, if the recipe defines the
layout()
method and specifies aself.folders.source = "src"
it won’t affect where the files (from theexports_sources
) are copied. They will be copied to the base source folder. So, if you want to replace some file that got into thesource()
method, you need to explicitly copy it from the parent folder or even better, fromself.export_sources_folder
.import os, shutil from conan import ConanFile from conan.tools.files import save, load class Pkg(ConanFile): ... exports_sources = "CMakeLists.txt" def layout(self): self.folders.source = "src" self.folders.build = "build" def source(self): # emulate a download from web site save(self, "CMakeLists.txt", "MISTAKE: Very old CMakeLists to be replaced") # Now I fix it with one of the exported files shutil.copy("../CMakeLists.txt", ".") shutil.copy(os.path.join(self.export_sources_folder, "CMakeLists.txt", "."))
generators¶
-
ConanFile.
generators
= []¶ List or tuple of strings with names of generators.
class MyLibConan(ConanFile): generators = "CMakeDeps", "CMakeToolchain"
The generators can also be instantiated explicitly in the <MISSING PAGE> generate() method.
from conan.tools.cmake import CMakeToolchain class MyLibConan(ConanFile): ... def generate(self): tc = CMakeToolchain(self) tc.generate()
Warning
Do not specify the same generator in the
generators
attribute and at thegenerate()
method at the same recipe, Conan will use both and unexpected results might happen.
build_policy¶
-
ConanFile.
build_policy
= None¶ Controls when the current package is built during a
conan install
. The allowed values are:"missing"
: Conan builds it from source if there is no binary available."never"
: This package cannot be built from sources, it is always created withconan export-pkg
None
(default value): This package won’t be build unless the policy is specified in the command line (e.g--build=foo*
)
class PocoTimerConan(ConanFile): build_policy = "always" # "missing"
upload_policy¶
-
ConanFile.
upload_policy
= None¶ Controls when the current package built binaries are uploaded or not
"skip"
: The precompiled binaries are not uploaded. This is useful for “installer” packages that just download and unzip something heavy (e.g. android-ndk), and is useful together with thebuild_policy = "missing"
class Pkg(ConanFile): upload_policy = "skip"
no_copy_source¶
-
ConanFile.
no_copy_source
= False¶ The attribute
no_copy_source
tells the recipe that the source code will not be copied from thesource_folder
to thebuild_folder
. This is mostly an optimization for packages with large source codebases or header-only, to avoid extra copies.If you activate it (
no_copy_source=True
), is mandatory that the source code must not be modified at all by the configure or build scripts, as the source code will be shared among all builds.The recipes should always use
self.source_folder
attribute, which will point to thebuild
folder whenno_copy_source=False
and will point to thesource
folder whenno_copy_source=True
.See also
Read <MISSING PAGE> header-only section for an example using
no_copy_source
attribute.
source_folder¶
-
ConanFile.
source_folder
¶ The folder in which the source code lives. The path is built joining the base directory (a cache directory when running in the cache or the
output folder
when running locally) with the value offolders.source
if declared in thelayout()
method.Returns: A string with the path to the source folder. Note that the base directory for the
source_folder
when running in the cache will point to the base folder of the build unless no_copy_source is set toTrue
. But anyway it will always point to the correct folder where the source code is.
export_sources_folder¶
-
ConanFile.
export_sources_folder
¶ The value depends on the method you access it:
- At
source(self)
: Points to the base source folder (that means self.source_folder but without taking into account thefolders.source
declared in thelayout()
method). The declared exports_sources are copied to that base source folder always. - At
exports_sources(self)
: Points to the folder in the cache where the export sources have to be copied.
Returns: A string with the mentioned path. See also
- Read <MISSING PAGE>
export_sources
method. - Read <MISSING PAGE>
source
method.
- At
build_folder¶
-
ConanFile.
build_folder
¶ The folder used to build the source code. The path is built joining the base directory (a cache directory when running in the cache or the
output folder
when running locally) with the value offolders.build
if declared in thelayout()
method.Returns: A string with the path to the build folder.
package_folder¶
-
ConanFile.
package_folder
¶ The folder to copy the final artifacts for the binary package. In the local cache a package folder is created for every different package ID.
Returns: A string with the path to the package folder.
The most common usage of self.package_folder
is to copy
the files at the <MISSING PAGE> package() method:
import os
from conan import ConanFile
from conan.tools.files import copy
class MyRecipe(ConanFile):
...
def package(self):
copy(self, "*.so", self.build_folder, os.path.join(self.package_folder, "lib"))
...
recipe_folder¶
-
ConanFile.
recipe_folder
= None¶ The folder where the recipe conanfile.py is stored, either in the local folder or in the cache. This is useful in order to access files that are exported along with the recipe, or the origin folder when exporting files in
export(self)
andexport_sources(self)
methods.
The most common usage of self.recipe_folder
is in the export(self)
and export_sources(self)
methods,
as the folder from where we copy the files:
from conan import ConanFile
from conan.tools.files import copy
class MethodConan(ConanFile):
exports = "file.txt"
def export(self):
copy(self, "LICENSE.md", self.recipe_folder, self.export_folder)
folders¶
<MISSING REFERENCE>
The folders
attribute has to be set only in the layout()
method.
- self.folders.source: To specify a folder where your sources are.
- self.folders.build: To specify a subfolder where the files from the build are (or will be).
- self.folders.generators: To specify a subfolder where to write the files from the generators and the toolchains (e.g. the xx-config.cmake files from the
CMakeDeps
generator).- self.folders.imports: To specify a subfolder where to write the files copied when using the
imports(self)
method in aconanfile.py
.- self.folders.root: To specify the relative path from the
conanfile.py
to the root of the project, in case theconanfile.py
is in a subfolder and not in the project root. If defined, all the other paths will be relative to the project root, not to the location of theconanfile.py
.- self.folders.subproject: To use together with
self.folders.root
, in case such a subproject needs to access some files that are located in a sibling folder.See also
Read more about the usage of the
layout()
in this tutorial.
cpp¶
-
ConanFile.
cpp
= None¶ Object storing all the information needed by the consumers of a package: include directories, library names, library paths… Both for editable and regular packages in the cache. It is only available at the
layout()
method.self.cpp.package
: For a regular package being used from the Conan cache. Same as declaringself.cpp_info
at thepackage_info()
method.self.cpp.source
: For “editable” packages, to describe the artifacts underself.source_folder
self.cpp.build
: For “editable” packages, to describe the artifacts underself.build_folder
.
See also
Read more about the CppInfo model.
Important
This attribute should be only filled in the <MISSING METHOD>
layout()
method.
cpp_info¶
buildenv_info¶
-
ConanFile.
buildenv_info
= None¶ For the dependant recipes, the declared environment variables will be present during the build process. Should be only filled in the
package_info()
method.Important
This attribute is only defined inside
package_info()
method being None elsewhere.def package_info(self): self.buildenv_info.append_path("PATH", self.package_folder)
See also
Check the reference of the Environment object to know how to fill the
self.buildenv_info
.
runenv_info¶
-
ConanFile.
runenv_info
= None¶ For the dependant recipes, the declared environment variables will be present at runtime. Should be only filled in the
package_info()
method.Important
This attribute is only defined inside
package_info()
method being None elsewhere.def package_info(self): self.runenv_info.define_path("RUNTIME_VAR", "c:/path/to/exe")
See also
Check the reference of the Environment object to know how to fill the
self.runenv_info
.
conf_info¶
-
ConanFile.
conf_info
= None¶ Configuration variables to be passed to the dependant recipes. Should be only filled in the
package_info()
method.
class Pkg(ConanFile):
name = "pkg"
def package_info(self):
self.conf_info.define("tools.microsoft.msbuild:verbosity", "Diagnostic")
self.conf_info.get("tools.microsoft.msbuild:verbosity") # == "Diagnostic"
self.conf_info.append("user.myconf.build:ldflags", "--flag3") # == ["--flag1", "--flag2", "--flag3"]
self.conf_info.update("tools.microsoft.msbuildtoolchain:compile_options", {"ExpandAttributedSource": "false"})
self.conf_info.unset("tools.microsoft.msbuildtoolchain:compile_options")
self.conf_info.remove("user.myconf.build:ldflags", "--flag1") # == ["--flag0", "--flag2", "--flag3"]
self.conf_info.pop("tools.system.package_manager:sudo")
See also
Read here the complete reference of self.conf_info.
dependencies¶
Conan recipes provide access to their dependencies via the
self.dependencies
attribute.class Pkg(ConanFile): requires = "openssl/0.1" def generate(self): openssl = self.dependencies["openssl"] # access to members openssl.ref.version openssl.ref.revision # recipe revision openssl.options openssl.settingsSee also
Read here the complete reference of self.dependencies.
conf¶
In the self.conf
attribute we can find all the conf entries declared in the <MISSING PAGE> [conf] section of the profiles.
in addition of the declared <MISSING PAGE> self.conf_info entries from the first level tool requirements.
The profile entries have priority.
from conan import ConanFile
class MyConsumer(ConanFile):
tool_requires = "my_android_ndk/1.0"
def generate(self):
# This is declared in the tool_requires
self.output.info("NDK host: %s" % self.conf.get("tools.android:ndk_path"))
# This is declared in the profile at [conf] section
self.output.info("Custom var1: %s" % self.conf.get("user.custom.var1"))
info¶
Object used in:
The <MISSING PAGE>
validate(self)
method to check if a current configuration of the package is correct or not:def validate(self): if self.info.settings.os == "Windows": raise ConanInvalidConfiguration("Package does not work in Windows!")
The <MISSING PAGE>
package(self)
method to control the unique ID for a package:def package_id(self): self.info.clear()
revision_mode¶
This attribute allow each recipe to declare how the revision for the recipe itself should be computed. It can take two different values:
"hash"
(by default): Conan will use the checksum hash of the recipe manifest to compute the revision for the recipe."scm"
: the commit ID will be used as the recipe revision if it belongs to a known repository system (Git or SVN). If there is no repository it will raise an error.
python_requires¶
This class attribute allows to define a dependency to another Conan recipe and reuse its code. Its basic syntax is:
from conan import ConanFile
class Pkg(ConanFile):
python_requires = "pyreq/0.1@user/channel" # recipe to reuse code from
def build(self):
self.python_requires["pyreq"].module # access to the whole conanfile.py module
self.python_requires["pyreq"].module.myvar # access to a variable
self.python_requires["pyreq"].module.myfunct() # access to a global function
self.python_requires["pyreq"].path # access to the folder where the reused file is
Read more about this attribute in Python requires
python_requires_extend¶
This class attribute defines one or more classes that will be injected in runtime as base classes of
the recipe class. Syntax for each of these classes should be a string like pyreq.MyConanfileBase
where the pyreq
is the name of a python_requires
and MyConanfileBase
is the name of the class
to use.
from conan import ConanFile
class Pkg(ConanFile):
python_requires = "pyreq/0.1@user/channel", "utils/0.1@user/channel"
python_requires_extend = "pyreq.MyConanfileBase", "utils.UtilsBase" # class/es to inject
conan_data¶
Read only attribute with a dictionary with the keys and values provided in a <MISSING PAGE> conandata_yml file format placed next to the conanfile.py. This YAML file is automatically exported with the recipe and automatically loaded with it too.
You can declare information in the conandata.yml file and then access it inside any of the methods of the recipe. For example, a conandata.yml with information about sources that looks like this:
sources:
"1.1.0":
url: "https://www.url.org/source/mylib-1.0.0.tar.gz"
sha256: "8c48baf3babe0d505d16cfc0cf272589c66d3624264098213db0fb00034728e9"
"1.1.1":
url: "https://www.url.org/source/mylib-1.0.1.tar.gz"
sha256: "15b6393c20030aab02c8e2fe0243cb1d1d18062f6c095d67bca91871dc7f324a"
def source(self):
tools.get(**self.conan_data["sources"][self.version])
deprecated¶
-
ConanFile.
deprecated
= None¶ This attribute declares that the recipe is deprecated, causing a user-friendly warning message to be emitted whenever it is used
For example, the following code:
from conan import ConanFile class Pkg(ConanFile): name = "cpp-taskflow" version = "1.0" deprecated = True
may emit a warning like:
cpp-taskflow/1.0: WARN: Recipe 'cpp-taskflow/1.0' is deprecated. Please, consider changing your requirements.
Optionally, the attribute may specify the name of the suggested replacement:
from conan import ConanFile class Pkg(ConanFile): name = "cpp-taskflow" version = "1.0" deprecated = "taskflow"
This will emit a warning like:
cpp-taskflow/1.0: WARN: Recipe 'cpp-taskflow/1.0' is deprecated in favor of 'taskflow'. Please, consider changing your requirements.
If the value of the attribute evaluates to
False
, no warning is printed.
provides¶
-
ConanFile.
provides
= None¶ This attribute declares that the recipe provides the same functionality as other recipe(s). The attribute is usually needed if two or more libraries implement the same API to prevent link-time and run-time conflicts (ODR violations). One typical situation is forked libraries. Some examples are:
- LibreSSL, BoringSSL and OpenSSL
- libav and ffmpeg
- MariaDB client and MySQL client
If Conan encounters two or more libraries providing the same functionality within a single graph, it raises an error:
At least two recipes provides the same functionality: - 'libjpeg' provided by 'libjpeg/9d', 'libjpeg-turbo/2.0.5'
The attribute value should be a string with a recipe name or a tuple of such recipe names.
For example, to declare that
libjpeg-turbo
recipe offers the same functionality aslibjpeg
recipe, the following code could be used:from conan import ConanFile class LibJpegTurbo(ConanFile): name = "libjpeg-turbo" version = "1.0" provides = "libjpeg"
To declare that a recipe provides the functionality of several different recipes at the same time, the following code could be used:
from conan import ConanFile class OpenBLAS(ConanFile): name = "openblas" version = "1.0" provides = "cblas", "lapack"
If the attribute is omitted, the value of the attribute is assumed to be equal to the current package name. Thus, it’s redundant for
libjpeg
recipe to declare that it provideslibjpeg
, it’s already implicitly assumed by Conan.
win_bash¶
-
ConanFile.
win_bash
= None¶ When
True
it enables the new run in a subsystem bash in Windows mechanism.from conan import ConanFile class FooRecipe(ConanFile): ... win_bash = True
It can also be declared as a
property
based on any condition:from conan import ConanFile class FooRecipe(ConanFile): ... @property def win_bash(self): return self.settings.arch == "armv8"