孵化功能

本节专门介绍正在开发中的新功能，旨在寻求用户测试和反馈。它们通常位于一个标志之后，以允许用户明确选择加入此测试阶段。它们需要最新的 Conan 版本（有时建议从 develop2 源代码分支运行），并显式设置这些标志。

新的 CMakeDeps 生成器

此生成器旨在替代当前的 CMakeDeps 生成器，其中包含多个待处理的修复和改进，这些修复和改进在当前的生成器中不容易完成，而不会破坏兼容性。

  • 创建真实的 SHARED/STATIC/INTERFACE IMPORTED 目标，不再有人工接口目标。CONAN_LIB:: 和其他类似的目标不再存在。

  • 为目标定义 IMPORTED_CONFIGURATIONS。

  • 依赖项的 CONFIG 定义与依赖项 Release/Debug/etc build_type 匹配，不再使用消费者的配置。

  • 为库目标定义 IMPORTED_LOCATION 和 IMPORTED_IMPLIB。

  • 基于配方 languages 和 cpp_info/component languages 属性定义 LINK_LANGUAGES。

  • 所有这些都允许更好地传播链接需求和可见性，避免 Linux 中传递共享库的一些链接错误。

  • 更好地定义同一软件包内部组件之间以及与其他软件包相关的 requires 关系。

  • 它不需要任何 build_context_activated 或 build_context_suffix 来使用 tool_requires 依赖项。

  • 定义 cpp_info/component.exe 信息（应包括 .location 定义），以定义可以运行的 EXECUTABLE 目标。

  • 来自 requires 的可执行文件也可以在非交叉构建场景中使用。当存在指向相同依赖项的 tool_requires 时，这些可执行文件将具有优先级。

  • 创建新的 conan_cmakedeps_paths.cmake，其中包含用于直接查找依赖项的 <pkg>_DIR 路径的定义。此文件也计划在 cmake-conan 中使用，以扩展其用途并避免当前由于 CMake 驱动的安装无法稍后注入工具链而导致的一些限制。

可以在 cpp_info 或 cpp_info.components 中定义的新字段，除了 CppInfo 中已定义的字段之外，还有

# EXPERIMENTAL FIELDS, used exclusively by new CMakeDeps (-c tools.cmake.cmakedeps:new)
self.cpp_info.type  # The type of this artifact "shared-library", "static-library", etc (same as package_type)
self.cpp_info.location # full location (path and filename with extension) of the artifact
self.cpp_info.link_location  # Location of the import library for Windows .lib associated to a dll
self.cpp_info.languages # same as "languages" attribute, it can be "C", "C++"
self.cpp_info.exe  # Definition of an executable artifact

这些字段将从其他 cpp_info 和 components 定义中自动推导出来，例如 libs 或 libdirs 字段，但自动推导可能存在限制。显式定义它们将禁止自动推导，并使用配方提供的值。

此功能通过 -c tools.cmake.cmakedeps:new=will_break_next 配置启用。值 will_break_next 将在后续版本中更改，以强调此功能不适合在测试之外使用。只需启用此配置并强制构建使用 CMakeDeps 的软件包，即可触发新生成器的使用。

当前已知限制

  • 目前，它仅限于 xxx-config.cmake 文件。它尚不会生成 find 模块。

  • conan_cmakedeps_paths.cmake 中的某些路径可能仍然缺失，目前除了软件包 <pkg>_DIR 位置之外，仅定义了 CMAKE_PROGRAM_PATH。

如有任何反馈，请在 https://github.com/conan-io/conan 中开启新的 issue。

工作区

可以通过定义环境变量 CONAN_WORKSPACE_ENABLE=will_break_next 来启用工作区功能。值 will_break_next 用于强调它将在后续版本中更改，并且此功能仅用于测试，不能在生产环境中使用。

启用该功能后，工作区由 conanws.yml 和/或 conanws.py 文件定义。默认情况下，任何 Conan 命令都会从当前工作目录向上遍历文件系统到文件系统根目录，直到找到其中一个文件。这将定义“根”工作区文件夹。

conan workspace 命令允许打开、添加、从当前工作区中删除软件包。查看 conan workspace -h 帮助和子命令的帮助以查看其用法。

添加到工作区的依赖项作为本地 editable 依赖项工作。它们仅在当前工作区下解析为 editable，如果当前目录移出工作区，则不再使用这些 editable 依赖项。

conanws 文件中的路径旨在相对于可重定位，或者可以提交到类似 Monorepo 项目的 Git 中。

conanws.yml 和 conanws.py 文件充当回退，也就是说，默认情况下，工作区将查找 conanws.py 内部的 editables() 函数，如果存在则使用它。否则，它将回退到 yml 文件中的 editables 定义。

工作区可以动态定义可编辑项，例如

conanws.py
import os
name = "myws"

workspace_folder = os.path.dirname(os.path.abspath(__file__))

def editables():
   result = {}
   for f in os.listdir(workspace_folder):
      if os.path.isdir(os.path.join(workspace_folder, f)):
            name = open(os.path.join(workspace_folder, f, "name.txt")).read().strip()
            version = open(os.path.join(workspace_folder, f,
                                       "version.txt")).read().strip()
            p = os.path.join(f, "conanfile.py").replace("\\\\", "/")
            result[f"{name}/{version}"] = {"path": p}
   return result

还有一个非常初步的 API，可用于加载 conanfile 以重用其 set_version() 方法，例如

import os
name = "myws"

def editables(*args, **kwargs):
      result = {}
      for f in os.listdir(workspace_api.folder):
         if os.path.isdir(os.path.join(workspace_api.folder, f)):
            f = os.path.join(f, "conanfile.py").replace("\\\\", "/")
            conanfile = workspace_api.load(f)
            result[f"{conanfile.name}/{conanfile.version}"] = {"path": f}
      return result

同样，home_folder 用于为此工作区定义可选的 Conan 缓存位置，将是一个回退。可以在 conanws.py 中定义一个变量，如果它不存在，它将回退到 conanws.yml 中的变量。home_folder() 也可以是一个函数，它使用来自 conanws.yml 的数据并动态扩展它，例如

def home_folder():
   # if the conanws.yml contains "myfolder", the Conan
   # cache will be in "newmyfolder" subfolder (relative
   # to the workspace root folder)
   return "new" + conanws_data["home_folder"]

conan workspace add/remove

使用这些命令向当前工作区添加或删除可编辑软件包。conan workspace add <path> 文件夹必须包含 conanfile.py。

conan workspace info

使用此命令显示有关当前工作区的信息

$ cd myfolder
$ conan new workspace
$ conan workspace info
WARN: Workspace found
WARN: Workspace is a dev-only feature, exclusively for testing
name: myfolder
folder: /path/to/myfolder
products
   app1
editables
   liba/0.1
      path: liba
   libb/0.1
      path: libb
   app1/0.1
      path: app1

conan workspace open

新的 conan workspace open 命令实现了一个新概念。那些在 conandata.yml 中包含 scm 信息（使用 git.coordinates_to_conandata()）的软件包可以从其 Conan 配方引用（包括配方修订）自动克隆和签出到当前工作区中。

conan new workspace

命令 conan new 学习了一个新的内置（实验性）模板 workspace，它创建一个包含一些可编辑软件包和一个表示它的 conanws.yml 的本地项目。它对于快速演示、概念验证和实验非常有用。

conan workspace build

命令 conan workspace build 执行与 conan build <product-path> --build=editable 等效的操作，对于工作区中定义的每个 product。

产品是“下游”使用者，是依赖关系图的“根”和起始节点。可以使用新的 --product 参数通过 conan workspace add <folder> --product 来定义它们。

限制

  • 目前，workspace 功能仅管理本地可编辑软件包。它不创建任何特定的元项目，也不执行任何协调构建。

  • conan workspace build 命令只是迭代所有产品，因此它可能会重复构建产品的可编辑依赖项。在大多数情况下，这将是空操作，因为项目已经构建完成，但仍然可能需要一些时间。这有待优化，但这将在稍后完成，现在重要的是关注工具、UX、流程和定义（例如 products 的定义）。

如有任何反馈，请在 https://github.com/conan-io/conan 中开启新的 issue。