本文档翻译自：https://docs.conan.io/en/latest/creating_packages/define_abi_compatibility.html
    每个包配方可以从中生成N个二进制包，具体取决于以下三个项目: settings, options 和 requires。当包配方的任何设置发生变化时，它将引用不同的二进制文件:

    1. class MyLibConanPackage(ConanFile):
    2.     name = "mylib"
    3.     version = "1.0"
    4.     settings = "os", "arch", "compiler", "build_type"

    当这个包由conanfile.txt、另一个包conanfile.py或直接安装时:

    1. $ conan install mylib/1.0@user/channel -s arch=x86_64 -s ...

    该流程为:

    1. Conan获取用户输入 settings 和 options。这些 settings 和 options 可以来自命令行、配置文件或最新的conan install执行中缓存的值。
    2. Conan检索mylib/1.0@user/channel配方，读取settings属性，并分配必要的值。
    3. 使用 settings的当前包值 (还有options和requires)，它将计算一个SHA1 哈希值，该哈希值将用作二进制包ID，例如，c6d75a933080ca17eb7f076813e7fb21aaa740f2.
    4. Conan将尝试查找c6d75...二进制包。如果它存在，它将被检索。如果找不到它，它将失败，并指示可以使用conan install -- build从源中构建它。

    如果使用不同的设置 (例如，在 32 位体系结构上) 再次安装软件包:

    1. $ conan install mylib/1.0@user/channel -s arch=x86 -s ...

    将使用不同的生成包ID重复该过程，因为arch设置了不同的值。这同样适用于不同的编译器、编译器版本和构建类型。生成多个二进制文件时-为每个配置生成一个单独的ID。

    当使用该软件包的开发人员使用与那些上载的二进制文件之一相同的设置时，计算出的软件包ID将相同，从而无需重新从源代码中重建二进制文件即可对其进行检索和重用。

    options 的行为非常相似。 主要区别在于，可以在软件包级别更轻松地定义选项，并且可以将其默认设置。 检查选项参考。

    请注意仅头文件库的简单场景。这种包不需要构建，也不会有任何ABI问题。此类包的配方将不再生成单个二进制包。这很容易通过在配方中不声明 settings 或 options 来实现，如下所示:

    1. class MyLibConanPackage(ConanFile):
    2.     name = "MyLib"
    3.     version = "1.0"
    4.     # no settings defined!

    无论用户定义了哪些设置（包括编译器或版本），程序包设置和选项都将始终相同（保留为空），并且它们将散列为相同的二进制程序包ID。 该软件包通常仅包含头文件。

    如果我们有一个可以用GCC 4.8构建并且可以保留ABI与GCC 4.9兼容性的库，会发生什么？ （例如，对于纯C库，这种兼容性更容易实现）。

    尽管可以说它也值得用4.9进行重建-以获得修复和性能改进-。 假设我们不想创建2个不同的二进制文件，而只是创建一个使用GCC 4.8构建的二进制文件，并且还需要与GCC 4.9安装兼容。