1.X 和 2.X 区别挺大的,2.X 更强了,这篇文章就是我学习2.X 的学习记录,耐心跟官网的教程走一遍,基本就会用这个工具了。
1.X 的文档:
https://docs.conan.io/en/1.46/introduction.html
2.X 的文档:
https://docs.conan.io/2/tutorial/consuming_packages.html
跟着官网教程做一遍。
1、pip install conan后,conan最新是2.0.x的版本;
2、CMakeLists.txt 里这样去找的:
3、conanfile.txt 写需要的包。
[generators] generators告诉Conan生成编译器或构建系统将用于查找依赖项和构建项目所需的文件。在这种情况下,由于我们的项目基于CMake,我们将使用CMakeDeps生成关于Zlib库文件安装位置的信息,并使用CMakeToolchain通过CMake工具链文件将构建信息传递给CMake。
4、Conan profile 是必须的文件。Conan配置文件允许用户定义一组配置,如编译器、构建配置、架构、共享或静态库等。Conan默认不会自动检测配置文件,因此我们需要创建一个配置文件。如果想让Conan尝试根据当前操作系统和已安装的工具来猜测配置文件,请运行以下命令:
cconan profile detect --force
我用这个命令检测出来的还是有点错误,手动修改需要首先用这个指令看默认的文件在哪里:
cconan profile path default
然后修改成自己想要的:
5、最终使用conan install。
Conan从我们在教程开始时配置的远程服务器上安装了Zlib库。该服务器存储了Conan配方,这些配方定义了如何构建库,并且还存储了可以重用的二进制文件,因此我们不必每次都从源代码构建。
Conan在build文件夹下生成了几个文件。这些文件由我们在conanfile.txt中设置的CMakeToolchain和CMakeDeps生成器生成。CMakeDeps生成文件以便CMake可以找到我们刚刚下载的Zlib库。另一方面,CMakeToolchain为CMake生成一个工具链文件,以便我们可以使用与默认配置文件检测到的相同设置透明地使用CMake构建项目。
cconan install . --output-folder=build --build=missing
Conan可以帮你搞定不同版本的CMake。你只要在conanfile.txt写出:
c[tool_requires]
cmake/3.22.6
可以在Conan中声明此依赖关系,使用一种名为tool_requires的要求类型。让我们看一个示例,了解如何向我们的项目添加tool_requires,并使用不同的CMake版本来构建它。
这个操作会在build文件夹中产生一个cmake的可执行程序,可以用你想要的cmake版本去编译程序:
目前为止,我们构建了一个简单的CMake项目,该项目依赖于zlib库,并学习了tool_requires,这是一种用于构建工具(如CMake)的特殊要求类型。在这两种情况下,我们没有在任何地方指定我们希望以发布模式还是调试模式构建应用程序,或者我们希望链接静态库还是共享库。这是因为如果没有另外指示,Conan将使用在“default profile”中声明的默认配置。在第一个示例中运行conan profile detect命令时,该默认配置文件是自动生成的。
Conan profile有不同的部分。[settings]部分包含有关操作系统、架构、编译器和构建配置等信息。当您调用Conan命令并设置--profile参数时,Conan将获取配置文件中的所有信息,并应用于您要构建或安装的软件包。如果您没有指定该参数,相当于使用--profile=default进行调用。这两个命令的行为是相同的:
c$ conan install . --build=missing
$ conan install . --build=missing --profile=default
您可以存储不同的配置文件,并使用它们来针对不同的设置进行构建。例如,可以使用build_type=Debug,或在使用该配置文件构建的所有软件包中添加tool_requires。一个调试配置文件的示例如下所示:
c[settings]
os=Macos
arch=x86_64
compiler=apple-clang
compiler.version=14.0
compiler.libcxx=libc++
compiler.cppstd=gnu11
build_type=Debug
使用配置文件Conan profile不是设置要使用的配置的唯一方法。您还可以在Conan命令中使用--settings参数覆盖配置文件Conan profile中的设置。例如,您可以在调试配置中构建先前示例中的项目,而不是发布配置。
c$ conan install . --output-folder=build --build=missing --settings=build_type=Debug
到目前为止,我们一直在应用程序中静态链接Zlib。这是因为在Zlib的Conan包中,默认设置了以静态方式构建的属性。我们可以通过使用--options参数将shared选项设置为True,来改变从静态链接到共享链接。请执行以下命令来进行设置:
cconan install . --output-folder=build --build=missing --options=zlib/1.2.11:shared=True
这样做后,Conan将安装Zlib的共享库,生成使用它们构建的文件,并且还会在运行应用程序时生成必要的文件来定位这些动态库。在将应用程序配置为使用共享库链接Zlib之后,让我们再次构建应用程序:
c$ cd build $ cmake .. -DCMAKE_TOOLCHAIN_FILE=conan_toolchain.cmake -DCMAKE_BUILD_TYPE=Release $ cmake --build . --config Release
现在,如果您尝试运行编译后的可执行文件,您会看到一个错误,因为该可执行文件找不到我们刚刚安装的Zlib的共享库。
c$ ./compressor
这是因为共享库(在Windows中是.dll,在OSX中是.dylib,在Linux中是.so)是在运行时加载的。这意味着应用程序可执行文件需要知道在运行时需要哪些共享库的位置。在Windows上,动态链接器将先搜索相同的目录,然后再搜索PATH目录。在OSX上,它将搜索在DYLD_LIBRARY_PATH中声明的目录,而在Linux上则使用LD_LIBRARY_PATH。
Conan提供了一种机制来定义这些变量,并使可执行文件能够找到和加载这些共享库。这个机制是VirtualRunEnv生成器。如果您检查输出文件夹,您会看到Conan生成了一个名为conanrun.sh/bat的新文件。这是在进行conan安装时激活共享选项时自动调用VirtualRunEnv生成器的结果。这个生成的脚本将设置PATH、LD_LIBRARY_PATH、DYLD_LIBRARY_PATH和DYLD_FRAMEWORK_PATH环境变量,以便可执行文件可以找到共享库。
c$ source conanrun.sh $ ./compressor
从conanfile.txt迁移到conanfile.py,可以提供更高的灵活性。下面的这个是conanfile.txt:
c[requires]
zlib/1.2.11
[tool_requires]
cmake/3.22.6
[generators]
CMakeDeps
CMakeToolchain
等价于下面这个conanfile.py,继承ConanFile类,复写属性settings、generators,方法self.requires、self.tool_requires表述需求。
cfrom conan import ConanFile
class CompressorRecipe(ConanFile):
settings = "os", "compiler", "build_type", "arch"
generators = "CMakeToolchain", "CMakeDeps"
def requirements(self):
self.requires("zlib/1.2.11")
def build_requirements(self):
self.tool_requires("cmake/3.22.6")
在之前的示例中,每次执行conan install命令时,我们都必须使用--output-folder参数来定义我们想要创建Conan生成文件的位置。有一种更简洁的方法可以决定我们希望Conan为构建系统生成文件的位置,这样我们可以根据所使用的CMake生成器的类型决定是否使用不同的输出文件夹。你可以直接在conanfile.py文件中的layout()方法中定义这个位置,并使其适用于每个平台,而不需要添加更多的更改。
cimport os
from conan import ConanFile
class CompressorRecipe(ConanFile):
settings = "os", "compiler", "build_type", "arch"
generators = "CMakeToolchain", "CMakeDeps"
def requirements(self):
self.requires("zlib/1.2.11")
def build_requirements(self):
self.tool_requires("cmake/3.22.6")
def layout(self):
# We make the assumption that if the compiler is msvc the
# CMake generator is multi-config
multi = True if self.settings.get_safe("compiler") == "msvc" else False
if multi:
self.folders.generators = os.path.join("build", "generators")
else:
self.folders.generators = os.path.join("build", str(self.settings.build_type), "generators")
正如你所看到的,我们在layout()方法中定义了self.folders.generators属性。这是Conan生成的所有辅助文件(CMake工具链和CMake依赖文件)放置的文件夹。
请注意,如果是多配置生成器(如Visual Studio),文件夹的定义与单配置生成器(如Unix Makefiles)不同。在第一种情况下,无论构建类型如何,文件夹都是相同的,构建系统将在该文件夹内管理不同的构建类型。但是像Unix Makefiles这样的单配置生成器,必须为每个不同的配置(如不同的构建类型Release/Debug)使用不同的文件夹。在这种情况下,我们添加了一个简单的逻辑来判断如果编译器名称是msvc,则考虑多配置。请注意,如果运行与之前示例中相同的命令但没有--output-folder参数,将会得到与之前相同的结果。
使用raise ConanInvalidConfiguration去引发异常:
c...
from conan.errors import ConanInvalidConfiguration
class CompressorRecipe(ConanFile):
...
def validate(self):
if self.settings.os == "Macos" and self.settings.arch == "armv8":
raise ConanInvalidConfiguration("ARM v8 not supported in Macos")
交叉编译:比如编译平台是ubuntu,而运行平台是Android。
之前写的:
c$ conan install . --build=missing --profile=someprofile
其实是等价于:
c$ conan install . --build=missing --profile:host=someprofile --profile:build=default
profile:host: 这是定义构建二进制文件所运行平台的配置文件。【运行平台是Android】
profile:build: 这是定义构建二进制文件的平台的配置文件。【编译平台是ubuntu】
请注意,当您只使用一个参数来确定配置文件时,--profile与--profile
等效。如果您不指定--profile参数,Conan将在内部使用default 配置文件。conanfile.py
cfrom conan import ConanFile
class CompressorRecipe(ConanFile):
settings = "os", "compiler", "build_type", "arch"
generators = "CMakeToolchain", "CMakeDeps"
def requirements(self):
self.requires("zlib/[~1.2]")
zlib/[~1.2]
,意味着在conan center 找类似于zlib/1.2.8, zlib/1.2.11 or zlib/1.2.12中的最新版本包。
zlib/[<1.2.12]
,如果这么写,就是找这个版本以下的,不包含这个版本。类似地使用大于小于等于就可以了。
self.tool_requires("cmake/[>3.10]")
也服从这个规则。
本文作者:Dong
本文链接:
版权声明:本博客所有文章除特别声明外,均采用 CC BY-NC。本作品采用《知识共享署名-非商业性使用 4.0 国际许可协议》进行许可。您可以在非商业用途下自由转载和修改,但必须注明出处并提供原作者链接。 许可协议。转载请注明出处!