为多种配置构建:Release、Debug、Static 和 Shared¶
请首先克隆源代码以重新创建此项目。您可以在 GitHub 的 examples2 仓库中找到它们。
$ git clone https://github.com/conan-io/examples2.git
$ cd examples2/tutorial/consuming_packages/different_configurations
到目前为止,我们构建了一个依赖于 zlib 库的简单 CMake 项目,并了解了 tool_requires,这是一种特殊的 requirements,用于 CMake 等构建工具。在这两种情况下,我们都没有在任何地方指定我们要以 Release 或 Debug 模式构建应用程序,或者我们要链接 static 或 shared 库。这是因为 Conan,如果未另行指示,将使用在“default profile”中声明的默认配置。此默认配置文件在我们运行 conan profile detect 命令时在第一个示例中创建。Conan 将此文件存储在 Conan 用户主目录下的 /profiles 文件夹中。您可以通过运行 conan config home 命令来获取 Conan 用户主目录的位置,然后显示 /profiles 文件夹中的默认配置文件的内容来检查您的默认配置文件的内容。
$ conan config home
Current Conan home: /Users/tutorial_user/.conan2
# output the file contents
$ cat /Users/tutorial_user/.conan2/profiles/default
[settings]
os=Macos
arch=x86_64
compiler=apple-clang
compiler.version=14.0
compiler.libcxx=libc++
compiler.cppstd=gnu11
build_type=Release
[options]
[tool_requires]
[env]
# The default profile can also be checked with the command "conan profile show"
如您所见,配置文件有不同的部分。 [settings] 部分包含有关操作系统、架构、编译器和构建配置等信息。
当您调用 Conan 命令设置 --profile 参数时,Conan 将获取配置文件中的所有信息并将其应用于您要构建或安装的包。如果您不指定该参数,则等同于使用 --profile=default 调用它。这两个命令的行为相同
$ conan install . --build=missing
$ conan install . --build=missing --profile=default
您可以存储不同的配置文件并使用它们为不同的设置构建。例如,使用 build_type=Debug,或者将 tool_requires 添加到您使用该配置文件构建的所有包中。我们将创建一个 debug 配置文件来尝试使用不同的配置进行构建
[settings]
os=Macos
arch=x86_64
compiler=apple-clang
compiler.version=14.0
compiler.libcxx=libc++
compiler.cppstd=gnu11
build_type=Debug
修改设置:为应用程序及其依赖项使用 Debug 配置¶
使用配置文件并不是设置所需配置的唯一方法。您还可以使用 --settings 参数在 Conan 命令中覆盖配置文件设置。例如,您可以像在前一个示例中一样,以 Debug 配置而不是 Release 配置构建项目。
构建之前,请检查我们是否修改了前一个示例中的源代码,以显示构建配置的来源
#include <stdlib.h>
...
int main(void) {
...
#ifdef NDEBUG
printf("Release configuration!\n");
#else
printf("Debug configuration!\n");
#endif
return EXIT_SUCCESS;
}
现在让我们为 Debug 配置构建我们的项目
$ conan install . --output-folder=build --build=missing --settings=build_type=Debug
如上所述,这等同于拥有 debug 配置文件并使用 --profile=debug 参数而不是 --settings=build_type=Debug 参数运行这些命令。
此 conan install 命令将检查我们是否已在本地缓存(Zlib)中为 Debug 配置拥有所需的库,如果没有则获取它们。它还将更新 conan_toolchain.cmake 和 CMakePresets.json 文件中的构建配置,这些文件由 CMakeToolchain 生成器创建,以便在我们构建应用程序时,它以 Debug 配置进行构建。现在,像在前面的示例中一样构建您的项目,并在输出中查看它是如何以 Debug 配置构建的
# assuming Visual Studio 15 2017 is your VS version and that it matches your default profile
$ cd build
$ cmake .. -G "Visual Studio 15 2017" -DCMAKE_TOOLCHAIN_FILE=conan_toolchain.cmake
$ cmake --build . --config Debug
$ Debug\compressor.exe
Uncompressed size is: 233
Compressed size is: 147
ZLIB VERSION: 1.2.11
Debug configuration!
$ cd build
$ cmake .. -DCMAKE_TOOLCHAIN_FILE=conan_toolchain.cmake -DCMAKE_BUILD_TYPE=Debug
$ cmake --build .
$ ./compressor
Uncompressed size is: 233
Compressed size is: 147
ZLIB VERSION: 1.2.11
Debug configuration!
修改选项:将应用程序依赖项链接为共享库¶
到目前为止,我们一直在应用程序中静态链接 Zlib。这是因为 Zlib 的 Conan 包默认设置为在此模式下构建。我们可以通过使用 --options 参数将 shared 选项设置为 True 来从 static 更改为 shared 链接。为此,请运行
$ conan install . --output-folder=build --build=missing --options=zlib/1.3.1:shared=True
这样做,Conan 将安装 Zlib 共享库,生成用于构建它们的文件的,以及在运行应用程序时定位这些动态库所需的文件的。
注意
选项是按包定义的。在这种情况下,我们定义了我们想要特定版本 zlib/1.3.1 作为共享库。如果我们有其他依赖项,并且我们希望所有依赖项(在可能的情况下)都是共享库,我们将使用 -o *:shared=True,其中 * 模式匹配所有包引用。
在将 Zlib 配置为共享库后,让我们再次构建应用程序
$ cd build
# assuming Visual Studio 15 2017 is your VS version and that it matches your default profile
$ cmake .. -G "Visual Studio 15 2017" -DCMAKE_TOOLCHAIN_FILE=conan_toolchain.cmake
$ cmake --build . --config Release
...
[100%] Built target compressor
$ cd build
$ cmake .. -DCMAKE_TOOLCHAIN_FILE=conan_toolchain.cmake -DCMAKE_BUILD_TYPE=Release
$ cmake --build .
...
[100%] Built target compressor
现在,如果您尝试运行编译后的可执行文件,您将看到一个错误,因为可执行文件找不到我们刚刚安装的 Zlib 的共享库。
$ Release\compressor.exe
(on a pop-up window) The code execution cannot proceed because zlib1.dll was not found. Reinstalling the program may fix this problem.
# This error depends on the console being used and may not always pop up.
# It could run correctly if the console gets the zlib dll from a different path.
$ ./compressor
./compressor: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory
$ ./compressor
./compressor: dyld[41259]: Library not loaded: @rpath/libz.1.dylib
这是因为共享库(Windows 上为 .dll,macOS 上为 .dylib,Linux 上为 .so)在运行时加载。这意味着可执行文件在运行时需要知道所需的共享库在哪里。在 Windows 上,动态链接器将在同一目录中搜索,然后在 PATH 目录中搜索。在 macOS 上,它将在 DYLD_LIBRARY_PATH 中声明的目录中搜索,在 Linux 上,它将使用 LD_LIBRARY_PATH。
Conan 提供了一种机制来定义这些变量,并使可执行文件能够找到和加载这些共享库。这种机制是 VirtualRunEnv 生成器。如果您查看输出文件夹,您会发现 Conan 生成了一个名为 conanrun.sh/bat 的新文件。这是我们在 conan install 中激活 shared 选项时自动调用 VirtualRunEnv 生成器的结果。此生成的脚本将设置 PATH、LD_LIBRARY_PATH、DYLD_LIBRARY_PATH 和 DYLD_FRAMEWORK_PATH 环境变量,以便可执行文件可以找到共享库。
激活虚拟环境,然后再次运行可执行文件
$ conanrun.bat
$ Release\compressor.exe
Uncompressed size is: 233
Compressed size is: 147
...
$ source conanrun.sh
$ ./compressor
Uncompressed size is: 233
Compressed size is: 147
...
与上一个示例中的 VirtualBuildEnv 生成器一样,当我们运行 conanrun.sh/bat 脚本时,会创建一个名为 deactivate_conanrun.sh/bat 的停用脚本来恢复环境。源文件或运行它以执行此操作
$ deactivate_conanrun.bat
$ source deactivate_conanrun.sh
设置和选项之间的区别¶
您可能已经注意到,我们使用 Conan setting 来在 Debug 和 Release 配置之间切换,但当设置可执行文件的 shared 模式时,我们使用了 Conan option。请注意 settings 和 options 之间的区别
settings 通常是客户端机器定义的项目范围配置。例如操作系统、编译器或构建配置,这些将是多个 Conan 包通用的,并且为其中一个包定义默认值没有意义。例如,Conan 包将“Visual Studio”声明为默认编译器没有意义,因为这是最终用户定义的,并且当他们在 Linux 上工作时不太可能适用。
options 用于包特定的配置,可以在配方中设置默认值。例如,一个包可以定义其默认链接是静态的,并且如果使用者未另行指定,则应使用此链接。
引入包 ID 概念¶
当使用不同的 settings 和 options 消费 Zlib 等包时,您可能想知道 Conan 如何确定从远程服务器检索哪个二进制文件。答案在于 package_id 的概念。
package_id 是 Conan 用于确定包二进制兼容性的标识符。它基于多个因素计算,包括包的 settings、options 和依赖项。当您修改这些因素中的任何一个时,Conan 都会计算一个新的 package_id 来引用相应的二进制文件。
以下是过程的细分
确定设置和选项:Conan 首先检索用户的输入设置和选项。这些可以来自命令行或配置文件,例如 –settings=build_type=Debug 或 –profile=debug。
计算包 ID:有了 settings、options 和依赖项的当前值,Conan 会计算一个哈希。此哈希用作 package_id,代表二进制包的唯一标识。
获取二进制文件:Conan 然后在其缓存或指定的远程服务器中查找具有计算出的 package_id 的二进制包。如果找到匹配项,它将检索该二进制文件。如果没有,Conan 可以从源代码构建包或指示二进制文件丢失。
在我们教程的上下文中,当我们使用不同的 settings 和 options 消费 Zlib 时,Conan 使用 package_id 来确保它获取与我们指定的配置匹配的正确二进制文件。