profiles

Introduction to profiles

Conan profiles 允许用户在一个文件中设置一套完整的 **settings**、**options**、**environment variables**(用于构建时和运行时上下文)、**tool requirements** 和 **configuration variables**。

它们有这样的结构

[settings]
arch=x86_64
build_type=Release
os=Macos

[options]
mylib/*:shared=True

[tool_requires]
tool1/0.1@user/channel
*: tool4/0.1@user/channel

[buildenv]
VAR1=value

[runenv]
EnvironmentVar1=My Value

[conf]
tools.build:jobs=2

[replace_requires]
zlib/1.2.12: zlib/[*]

[replace_tool_requires]
7zip/*: 7zip/system

[platform_requires]
dlib/1.3.22

[platform_tool_requires]
cmake/3.24.2

可以使用 conan profile 命令中的 detect 选项创建 profiles,然后稍后编辑。如果您不指定一个 *name*,该命令将创建 default profile。

创建 Conan 的默认 profile
$ conan profile detect
apple-clang>=13, using the major as version
Detected profile:
[settings]
arch=x86_64
build_type=Release
compiler=apple-clang
compiler.cppstd=gnu17
compiler.libcxx=libc++
compiler.version=14
os=Macos

WARN: This profile is a guess of your environment, please check it.
WARN: Defaulted to cppstd='gnu17' for apple-clang.
WARN: The output of this command is not guaranteed to be stable and can change in future Conan versions.
WARN: Use your own profile files for stability.
Saving detected profile to [CONAN_HOME]/profiles/default

注意

关于 Conan 检测到的 C++ 标准的说明

Conan 总是会将默认的 C++ 标准设置为已检测到的编译器版本默认使用的标准,macOS 使用 apple-clang 的情况除外。在这种情况下,对于 apple-clang>=11,它会设置为 compiler.cppstd=gnu17。如果您想使用不同的 C++ 标准,可以直接编辑默认的 profile 文件。

创建另一个 profile:myprofile
$ conan profile detect --name myprofile
Found apple-clang 14.0
apple-clang>=13, using the major as version
Detected profile:
[settings]
arch=x86_64
build_type=Release
compiler=apple-clang
compiler.cppstd=gnu17
compiler.libcxx=libc++
compiler.version=14
os=Macos

WARN: This profile is a guess of your environment, please check it.
WARN: Defaulted to cppstd='gnu17' for apple-clang.
WARN: The output of this command is not guaranteed to be stable and can change in future Conan versions.
WARN: Use your own profile files for stability.
Saving detected profile to [CONAN_HOME]/profiles/myprofile

Profile 文件可以与许多命令(如 conan installconan create 命令)中的 -pr/--profile 选项一起使用。如果您根本不指定任何 profile,将始终使用 default profile。

使用“default”profile
$ conan create .
使用“myprofile”profile
$ conan create . -pr=myprofile

Profile 文件可以包含注释,但仅限于新行,且第一个字符必须是 #。不支持行尾注释。

[settings]
# Valid comment
arch=x86_64
build_type=Release  # INVALID comment, do not use

Using profiles

Profiles 可以位于不同的文件夹中

$ conan install . -pr /abs/path/to/myprofile   # abs path
$ conan install . -pr ./relpath/to/myprofile   # resolved to current dir
$ conan install . -pr ../relpath/to/myprofile  # resolved to relative dir
$ conan install . -pr myprofile  # resolved to [CONAN_HOME]/profiles/myprofile

可以使用以下方式列出 *profiles* 文件夹中现有的 profiles

$ conan profile list
Profiles found in the cache:
default
myprofile1
myprofile2
...

您还可以按上下文显示 profile 的内容

$ conan profile show -pr myprofile
Host profile:
[settings]
arch=x86_64
build_type=Release
compiler=apple-clang
compiler.cppstd=gnu17
compiler.libcxx=libc++
compiler.version=14
os=Macos

Build profile:
[settings]
arch=x86_64
build_type=Release
compiler=apple-clang
compiler.cppstd=gnu17
compiler.libcxx=libc++
compiler.version=14
os=Macos

另请参阅

Profile sections

以下是 profiles 中可用的 sections

[settings]

来自 settings.yml 的设置列表

myprofile
[settings]
arch=x86_64
build_type=Release
compiler=apple-clang
compiler.cppstd=gnu17
compiler.libcxx=libc++
compiler.version=14
os=Macos

另请参阅

  • 此 section 允许使用模式来限制哪些包会受到设置的影响。有关更多详细信息,请参阅 此 section

[options]

来自您的 recipe 及其依赖项的 options 列表

myprofile
[options]
mypkg/*:my_pkg_option=True
*:shared=True

另请参阅

  • 此 section 允许使用模式来限制哪些包会受到 options 的影响。有关更多详细信息,请参阅 此 section

[tool_requires]

您的 recipe 或其依赖项所需的 tool_requires 列表

myprofile
[tool_requires]
cmake/3.25.2

另请参阅

  • 此 section 允许使用模式来限制哪些包会受到 tool requirement 的影响。有关更多详细信息,请参阅 此 section

  • 在此 section 阅读更多关于 tool requires 的信息:将构建工具用作 Conan 包

[system_tools] (DEPRECATED)

注意

此 section 已被 **弃用**,已被 [platform_requires][platform_tool_requires] sections 取代。

[buildenv]

每次调用 ConanFile 的 run(cmd, env="conanbuild") 方法时(构建时上下文由 VirtualBuildEnv 自动运行),都将注入到环境中的环境变量列表。

此外,它还能够在使用组合 profiles 或甚至本地变量时,对声明的每个变量应用一些附加运算符。

  • += == append:将值附加到现有值的末尾。

  • =+ == prepend:将值放在现有值的前面。

  • =! == unset:移除任何变量值。

请注意,定义一个空变量(如 MyVar1=)与使用 MyVar1=! 语法明确取消设置变量是不同的。前者将其定义为空字符串值,后者则显式取消设置。

另一个需要提到的关键点是,通过在变量前加上 (path) 前缀,可以将变量定义为 PATH 变量。这在不同系统上(Windows 使用 ; 作为分隔符,UNIX 使用 :)自动实现 PATH 的追加/前置非常有用。

myprofile
[buildenv]
# Define a variable "MyVar1"
MyVar1=My Value; other

# Append another value to "MyVar1"
MyVar1+=MyValue12

# Define a variable with an empty string value
MyVar2=

# Define a PATH variable "MyPath1"
MyPath1=(path)/some/path11

# Prepend another PATH to "MyPath1"
MyPath1=+(path)/other path/path12

# Unset the variable "MyPath2"
MyPath2=!

然后,应用此 profile 的结果是

  • MyVar1: My Value; other MyValue12

  • MyVar2: 空字符串值

  • MyPath1:
    • Unix: /other path/path12:/some/path11

    • Windows: /other path/path12;/some/path11

  • MyPath2: 如果系统环境变量已定义 MyPath2,则将被 Conan 取消设置

警告

请注意,[buildenv][runenv] 环境变量的定义会保留值中的用户空格。 MYVAR = MyValue 会产生 " MyValue" 的值,这与 MYVAR=MyValue(会产生 "MyValue")不同。请避免在 profiles 中在 = 周围使用额外的空格,而是使用上面所示的语法。

另请参阅

  • 此 section 允许使用模式来限制哪些包会受到 buildenv 的影响。有关更多详细信息,请参阅 此 section

例如

[buildenv]
MyPath=MyValue
mypkg/*:MyPath=MyOtherValue

这将导致所有包的 MyPath=MyValue,而仅 mypkg 包的 MyPath=MyOtherValue

[runenv]

每次调用 ConanFile 的 run(cmd, env="conanrun") 方法时(运行时上下文由 VirtualRunEnv 自动运行),都将注入到环境中的环境变量列表。

[buildenv] 解释的所有运算符/模式同样适用于此 section。

myprofile
[runenv]
MyVar1=My Value; other
MyVar1+=MyValue12
MyPath1=(path)/some/path11
MyPath1=+(path)/other path/path12
MyPath1=!

另请参阅

  • 此 section 允许使用模式来限制哪些包会受到 runenv 的影响。有关更多详细信息,请参阅 此 section

[conf]

注意

建议您事先阅读 global.conf section。

用户/工具配置列表

myprofile
[conf]
tools.build:verbosity=verbose
tools.microsoft.msbuild:max_cpu_count=2
tools.microsoft.msbuild:vs_version = 16
tools.build:jobs=10
# User conf variable
user.confvar:something=False

回忆一些关于配置范围和命名的提示

  • core.xxx 配置只能在 global.conf 文件中定义,而不能在 profiles 中定义。

  • tools.yyyuser.zzz 可以在 global.conf 中定义,并且会影响“build”和“host”上下文。“build”或“host”上下文的配置仅影响 profiles 的相应“build”或“host”上下文,而不是两者都影响。

它们也可以在 global.conf 中使用,但 **profiles 的值将优先于 global.conf 中全局定义的值**。因此,让我们看一个更复杂的示例,尝试来自 *global.conf* 和另一个 profile *myprofile* 的不同配置。

global.conf
# Defining several lists
user.myconf.build:ldflags=["--flag1 value1"]
user.myconf.build:cflags=["--flag1 value1"]
myprofile
[settings]
...

[conf]
# Appending values into the existing list
user.myconf.build:ldflags+=["--flag2 value2"]

# Unsetting the existing value (it'd be like we define it as an empty value)
user.myconf.build:cflags=!

# Prepending values into the existing list
user.myconf.build:ldflags=+["--prefix prefix-value"]

例如,运行 conan install . -pr myprofile,配置输出将类似于

...
Configuration:
[settings]
[options]
[tool_requires]
[conf]
user.myconf.build:cflags=!
user.myconf.build:ldflags=['--prefix prefix-value', '--flag1 value1', '--flag2 value2']
...

另请参阅

  • 此 section 允许使用模式来限制哪些包会受到 confs 的影响。有关更多详细信息,请参阅 此 section

[replace_requires]

警告

此功能是实验性的,可能会发生重大更改。有关更多信息,请参阅 Conan 稳定性 部分。

此 section 允许用户重新定义 recipes 的 requires。当一个包可以被类似的包(如 zlibzlibng)替换时,这很有用。它也有助于解决冲突,或将某些依赖项替换为包装在另一个 Conan 包 recipe 中的系统替代项。

此 section 下列出的引用在处理 recipe 需求之前,作为 **recipe 中 requires 的字面替换** 进行,并且在任何其他 recipe 需求处理之前完成,不会进行处理或冲突检查。

例如,我们可以将 zlibng 定义为标准 zlib 的替代项

myprofile
[replace_requires]
zlib/*: zlibng/*

zlibng 引用使用 * 模式意味着 zlib 将被 zlibng 的确切版本替换。

其他示例包括

myprofile
[replace_requires]
# To override dep/[>=1.0 <2] in recipes to a specific version dep/1.1)
dep/*: dep/1.1
# To override a dep/1.3 in recipes to dep/1.3@system
dep/*: dep/*@system
# To override every dep requirement in recipes to a specific version range
dep/*: dep/[>=1 <2]
# To override "dep/1.3@comp/stable" in recipes to the same version with other user but same channel
dep/*@*/*: dep/*@system/*
# To replace exact reference in recipes by the same one in the system
dep/1.1: dep/1.1@system
# To replace dep/[>=1.0 <2]@comp version range in recipes by 1.1 version in stable channel
dep/1.1@*: dep/1.1@*/stable

注意

最佳实践

  • 请理智地使用此功能。它不是版本控制机制,也不旨在取代 recipe 中的实际 requires。

  • 此功能的使用旨在 **暂时** 解决冲突或在某些交叉构建场景中用系统依赖项替换特定的依赖项。

[replace_tool_requires]

警告

此功能是实验性的,可能会发生重大更改。有关更多信息,请参阅 Conan 稳定性 部分。

replace_requires section 的用法相同,但在此情况下适用于 tool_requires

myprofile
[replace_tool_requires]
cmake/*: cmake/3.25.2

在这种情况下,recipe 中声明的任何版本的 cmake 都将被 cmake/3.25.2 引用替换。

注意

  • 此 section 应添加到需要 tool 的上下文所在的 profile 中,即,如果 tool 在 host 上下文中需要,则应将其添加到 host profile 中,以便 requirement 本身可以被替换。

[platform_requires]

警告

此功能是实验性的,可能会发生重大更改。有关更多信息,请参阅 Conan 稳定性 部分。

此 section 允许用户通过平台提供的依赖项重新定义 recipe 的 requires,这意味着 Conan 不会尝试下载该引用或在缓存中查找它,并会假定它已安装在您的系统中并准备好使用。

例如,如果 zlib 1.3.1 库已安装在您的系统中,或者它是您的构建工具链的一部分,并且您希望 Conan 使用它,则可以如下指定

myprofile
[platform_requires]
zlib/1.3.1

[platform_tool_requires]

警告

此功能是实验性的,可能会发生重大更改。有关更多信息,请参阅 Conan 稳定性 部分。

platform_requires section 的用法相同,但在此情况下适用于 tool_requires,如 cmakemeson 等。

例如,假设您已在系统中安装了 cmake==3.24.2

$ cmake --version
cmake version 3.24.2

CMake suite maintained and supported by Kitware (kitware.com/cmake).

并且您的 recipe(或传递依赖项)中声明了 **tool_requires**,例如:

conanfile.py
from conan import ConanFile

class PkgConan(ConanFile):
    name = "pkg"
    version = "2.0"
    # ....

    # Exact version
    def build_requirements(self):
        self.tool_requires("cmake/3.24.2")

    # Or even version ranges
    def build_requirements(self):
        self.tool_requires("cmake/[>=3.20.0]")

在这种情况下,您可能希望使用已安装的 CMake 版本,因此只需在您的 profile 中将其声明为 platform_tool_requires 即可。

myprofile
...

[platform_tool_requires]
cmake/3.24.2

当您创建包时,您将看到构建 requirement 已因平台工具声明而满足。

$ conan create . -pr myprofile --build=missing
...
-------- Computing dependency graph --------
Graph root
    virtual
Requirements
    pkg/2.0#3488ec5c2829b44387152a6c4b013767 - Cache
Build requirements
    cmake/3.24.2 - Platform

-------- Computing necessary packages --------

-------- Computing necessary packages --------
pkg/2.0: Forced build from source
Requirements
    pkg/2.0#3488ec5c2829b44387152a6c4b013767:20496b332552131b67fb99bf425f95f64d0d0818 - Build
Build requirements
    cmake/3.24.2 - Platform

注意

  • 如果声明的 platform_tool_requires **没有严格匹配** tool_requires(版本或版本范围),那么 Conan 将像往常一样尝试远程或本地获取它们。

  • 此 section 应添加到需要 tool 的上下文所在的 profile 中,即,如果 tool 在 host 上下文中需要,则应将其添加到 host profile 中,以便 requirement 本身可以被平台 requirement 所取代。

Profile rendering

默认情况下,profiles 被渲染为 **jinja2** 模板。当 Conan 加载一个 profile 时,它会立即解析并渲染模板,该模板必须生成一个标准的文本 profile。

Profile 模板的一些功能包括

  • 由于 Python 的 platform 模块被添加到渲染上下文中,因此可以使用平台信息,例如获取当前的操作系统。

    profile_vars
    [settings]
    os = {{ {"Darwin": "Macos"}.get(platform.system(), platform.system()) }}
    
  • 可以通过 Python 的 os 模块读取环境变量,该模块被添加到渲染上下文中。

    profile_vars
    [settings]
    build_type = {{ os.getenv("MY_BUILD_TYPE") }}
    
  • 定义您自己的变量并在 profile 中使用它们

    profile_vars
    {% set os = "FreeBSD" %}
    {% set clang = "my/path/to/clang" %}
    
    [settings]
    os = {{ os }}
    
    [conf]
    tools.build:compiler_executables={'c': '{{ clang }}', 'cpp': '{{ clang + '++' }}' }
    
  • 连接和定义路径,包括引用当前 profile 目录。例如,可以定义一个旁边文件与 profile 位于同一目录的 toolchain。除了 os Python 模块,变量 profile_dir(指向当前 profile 文件夹)也被添加到上下文中。

    profile_vars
    [conf]
    tools.cmake.cmaketoolchain:toolchain_file = {{ os.path.join(profile_dir, "toolchain.cmake") }}
    
  • 从文件名获取设置,包括引用当前 profile 名称。例如,定义一个通用的 profile,该 profile 根据其文件名进行配置。变量 profile_name(指向当前 profile 文件名)被添加到上下文中。

    Linux-x86_64-gcc-12
    {% set os, arch, compiler, compiler_version = profile_name.split('-') %}
    [settings]
    os={{ os }}
    arch={{ arch }}
    compiler={{ compiler }}
    compiler.version={{ compiler_version }}
    
  • 执行外部命令并使用其输出。 subprocess 模块被添加到上下文中,因此您可以使用它来执行命令并捕获其输出。请注意,某些命令的 Conan 启动时间可能会受到影响,如果命令执行时间较长,因此请谨慎使用此功能。例如,获取已安装的编译器的版本(但在此情况下,您应该使用 detect_api.detect_default_compiler())。

    profile_vars
    {% set version = subprocess.check_output(['clang++', "-dumpversion"]).strip() %}
    [settings]
    compiler.version={{ version }}
    
  • 根据 profile 被渲染的上下文进行分支。 context 变量被注入,并且可以取值为 hostbuildNone。例如,您可以为 host 和 build 上下文定义不同的设置,而无需创建两个不同的 profile。

    profile_vars
    [settings]
    os=Linux
    compiler=gcc
    compiler.version=12
    {% if context == "host" %}
    compiler.cppstd=gnu17
    {% else %}
    compiler.cppstd=gnu20
    {% endif %}
    
  • 包含或导入 *profiles* 文件夹中的其他文件。

    profile_vars
    {% set a = "Debug" %}
    
    myprofile
    {% import "profile_vars" as vars %}
    [settings]
    build_type = {{ vars.a }}
    

    当使用相对路径包含或导入其他文件时,Jinja 渲染器会使用当前 profile 文件的基路径作为查找的第一个位置。如果此搜索失败,Jinja 渲染器还将开始在 Conan 主目录的 profiles 文件夹中(通常在 <userhome>/.conan2/profiles)进行查找。

  • jinja2 支持的任何其他功能都是可能的:for 循环、if-else 等。这对于为大型依赖图中的多个包定义自定义的 per-package 设置或选项非常有用。

Profile Rendering with ``detect_api``

警告

Stability Guarantees: detect_api 与 conan profile detect 类似,不提供强稳定性保证。

Usage Recommendations: detect_api 不是用于创建新命令或类似功能的常规 API。虽然自动检测可能很方便,但它并非适用于所有场景的推荐方法。此 API 是 Conan 的内部 API,仅用于 profile 和 *global.conf* 渲染。建议谨慎使用。

Conan 还将 detect_api 注入到 jinja 渲染上下文中。借助它,可以在 Jinja profile 模板中直接使用 Conan 的自动检测功能。这提供了一种根据环境动态确定某些设置的方法。

detect_api 可以在 profile 的 Jinja 模板中调用。例如,要检测操作系统和架构,您可以使用

[settings]
os={{detect_api.detect_os()}}
arch={{detect_api.detect_arch()}}

类似地,对于更高级的检测,如确定编译器、其版本以及相关的运行时,您可以使用

{% set compiler, version, compiler_exe = detect_api.detect_default_compiler() %}
{% set runtime, _ = detect_api.default_msvc_runtime(compiler) %}
[settings]
compiler={{compiler}}
compiler.version={{detect_api.default_compiler_version(compiler, version)}}
compiler.runtime={{runtime}}
compiler.cppstd={{detect_api.default_cppstd(compiler, version)}}
compiler.libcxx={{detect_api.detect_libcxx(compiler, version, compiler_exe)}}

detect_api reference:

  • detect_os(): 返回操作系统字符串(例如,“Windows”、“Macos”)。

  • detect_arch(): 返回系统架构字符串(例如,“x86_64”、“armv8”)。

  • detect_libc(ldd="/usr/bin/ldd"): **experimental** 返回一个元组,包含 C 库的名称(例如,“gnu”、“musl”)和版本(例如,“2.39”、“1.2.4”)。

  • detect_libcxx(compiler, version, compiler_exe=None): 返回 C++ 标准库字符串(例如,“libstdc++”、“libc++”)。

  • default_msvc_runtime(compiler): 返回运行时(例如,“dynamic”)及其版本(例如,“v143”)的元组。

  • default_cppstd(compiler, compiler_version): 返回默认 C++ 标准字符串(例如,“gnu14”)。

  • detect_default_compiler(): 返回编译器名称(例如,“gcc”)、其版本和可执行文件路径的元组。

  • detect_msvc_update(version): 返回 MSVC 更新版本字符串(例如,“12”代表 VS 17.12.1)。请注意,在 Conan profiles 中,compiler.update 设置接受 0 到 10 的值。要将 detect_msvc_update 的结果转换为 profiles 所需的格式,您可以执行以下操作:

    示例

    ...
    [settings]
    compiler=msvc
    compiler=194 # for msvc toolset starting in 14.40 (VS 17.10)
    # If we are using VS 17.12 we convert 12 to 2 so it's 194 with update 2
    compiler.update = "{{ (detect_api.detect_msvc_update(version) | int) % 10 }}"
    ...
    
  • default_msvc_ide_version(version): 返回 MSVC IDE 版本字符串(例如,“17”)。

  • default_compiler_version(compiler, version): 返回 Conan 在 profiles 中使用的默认版本,通常会省略一些不影响二进制兼容性的次要或补丁数字。

  • detect_gcc_compiler(compiler_exe="gcc"): 返回 gcc 的元组 (‘gcc’, version, executable)。

  • detect_intel_compiler(compiler_exe="icx"): 返回 intel-cc 的元组 (‘intel-cc’, version, executable)。

  • detect_suncc_compiler(compiler_exe="cc"): 返回 sun-cc 的元组 (‘sun-cc’, version, executable)。

  • detect_clang_compiler(compiler_exe="clang"): 返回 clangapple-clang 的元组 (‘clang’|’apple-clang’, version, executable)。

  • detect_msvc_compiler(): 检测编译器 (‘msvc’, version, None),即安装的最新 VS IDE 的默认版本。

  • detect_cl_compiler(compiler_exe="cl"): 检测 cl.exe 编译器的元组 (‘msvc’, version, executable)。

  • detect_sdk_version(sdk): 检测 Apple SDK 版本(非 Apple 平台为 None),针对给定的 sdk。等同于 xcrun -sdk {sdk} --show-sdk-version

Profile patterns

Profiles(以及定义设置或选项的任何地方)也支持模式定义,因此您可以为某些特定包覆盖某些设置、配置变量等。

zlib_clang_profile
[settings]
# Only for zlib
zlib/*:compiler=clang
zlib/*:compiler.version=3.5
zlib/*:compiler.libcxx=libstdc++11

# For the all the dependency tree
compiler=gcc
compiler.version=4.9
compiler.libcxx=libstdc++11

[options]
# shared=True option only for zlib package
zlib/*:shared=True

[buildenv]
# For the all the dependency tree
*:MYVAR=my_var

[conf]
# Only for zlib
zlib/*:tools.build:compiler_executables={'c': '/usr/bin/clang', 'cpp': '/usr/bin/clang++'}

您的构建工具将仅为 **zlib** 包定位 **clang** 编译器,而为您的依赖关系树中的其余部分使用 **gcc**(默认)。

重要

只写 zlib: 是已弃用的行为,将不起作用。您必须始终写入类似模式的表达式,例如 zlib*:zlib/*:zlib/1.*: 等。

它们也接受模式,例如 -s *@myuser/*,这意味着用户名为“myuser”的包将使用 clang 3.5 作为编译器,否则使用 gcc。

myprofile
[settings]
*@myuser/*:compiler=clang
*@myuser/*:compiler.version=3.5
*@myuser/*:compiler.libcxx=libstdc++11
compiler=gcc
compiler.version=4.9
compiler.libcxx=libstdc++11

还可以将 & 指定为包名。它将仅应用于消费者 conanfile(.py 或 .txt)。这是一个特殊情况,因为消费者 conanfile 可能没有声明 name,因此无法引用它。

myprofile
[settings]
&:compiler=gcc
&:compiler.version=4.9
&:compiler.libcxx=libstdc++11

也支持部分匹配,因此您可以定义一个像 zlib* 这样的模式来匹配所有 zlib 类似的库,它将匹配所有以 zlib 开头的,例如 zlibzlibngzlib/1.2.8@user/channel 等。

myprofile
[settings]
zlib*:compiler=clang
zlib*:compiler.version=3.5
zlib*:compiler.libcxx=libstdc++11

如果模式以 ! 开头,则将其视为排除模式,这意味着它将匹配除指定模式之外的所有内容。这对于上面提到的消费者 & 模式也适用。

使用排除模式时必须小心,因为如果不谨慎使用,它们可能导致意外结果。

例如,要为除 zlib 之外的所有包定义 shared=True 选项,您可以使用

myprofile
[options]
!zlib/*:shared=True

请注意,对于 msvc 编译器,compiler.runtime_type 设置会由 profile.py 插件根据 build_type 设置值自动初始化,因为这对于绝大多数情况来说是一个很好的默认值。这意味着用户定义 -s build_type=MinSizeRel 的情况,对于 msvc 编译器将默认获得 compiler.runtime_type=Release 的值。然而,对于特定包的设置,情况并非如此,并且 profile.py 插件不会自动为 msvc 定义 compiler.runtime_type,因此像 mydep/*:build_type=<build_type> 这样的操作不会自动定义 mydep/*:compiler.runtime_type

在某些情况下,可能希望取消定义某些特定包设置,假设该设置允许取消定义。在这种情况下,可以使用 ~ 语法,如下所示:

myprofile
[settings]
build_type=Release
mypkg/*:build_type=~

此语法将为所有包定义 build_type=Release,但 mypkg(任何版本)除外,它将保持 build_type 未定义,因为它从未被赋值。在 recipe 代码中,这意味着 self.settings.build_type 将是 None

Profile includes

您可以使用 include() 语句包含其他 profile 文件。路径可以是相对于当前 profile 的,绝对路径,或者是本地缓存中默认 profile 位置的 profile 名称。

include() 语句必须位于 profile 文件的顶部。

gcc_49
[settings]
compiler=gcc
compiler.version=4.9
compiler.libcxx=libstdc++11
myprofile
include(gcc_49)

[settings]
zlib/*:compiler=clang
zlib/*:compiler.version=3.5
zlib/*:compiler.libcxx=libstdc++11

注意

缓存中的 profiles 比当前工作目录中的 profiles 具有更高的优先级,因此如果您在缓存中有名为 myprofile 的 profile,它将被使用,而不是当前工作目录中的 profile。

要使用当前工作目录中的 profile,您可以使用

  • -pr ./myprofile 命令行选项,或

  • include(./myprofile) 在 profile 文件本身中。

使用 *myprofile* 的最终结果是

myprofile (virtual result)
[settings]
compiler=gcc
compiler.libcxx=libstdc++11
compiler.version=4.9
zlib/*:compiler=clang
zlib/*:compiler.libcxx=libstdc++11
zlib/*:compiler.version=3.5