孵化中的功能¶

本节专门介绍正在开发中的新功能，这些功能正在寻求用户测试和反馈。它们通常位于一个标志之后，以允许用户显式选择加入此测试阶段。它们需要最新的 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 驱动的安装无法稍后注入工具链而导致的一些限制。

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

# 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 文件。它还不会生成查找模块。
除了包的 <pkg>_DIR 位置之外，conan_cmakedeps_paths.cmake 中的某些路径可能仍然缺失，目前仅定义了 CMAKE_PROGRAM_PATH。

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

工作区¶

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

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

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

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

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 open 命令实现了一个新概念。那些在 conandata.yml 中包含 scm 信息（使用 git.coordinates_to_conandata()）的包可以从其 Conan 配方引用（包括配方修订版）自动克隆并签出到当前工作区中。

conanws 文件中的路径旨在是相对路径，以便在必要时可以重新定位，或者可以像在单仓库项目中那样提交到 Git。

限制

目前，workspace 功能仅管理本地可编辑包。它不会创建任何特定的元项目，也不会进行任何协调构建。
但请注意，可以使用 conan build . --build=editables 在整个工作区中进行协调构建，因为它将按正确的顺序构建工作区中的每个可编辑包。

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