Ninja: 相对 subninja 路径无法解析

所有路径都相对于构建目录，而不是包含 subninja 行的文件。

不过，这没有任何意义。 这意味着生成器将必须_所有_实现某种方式来为文件添加前缀，这意味着更改运行的工作目录命令（这可能会根据生成器/命令的运行方式改变构建配置的原始意图）。

那么， subninja与include的对比用例是什么？

具有相对于构建文件的路径的子忍者将很有用，因为配置为在自己的目录中运行的依赖项可以在无需修改其路径的情况下这样做，但仍可以对父忍者配置的依赖关系图做出贡献。

include功能将不会被修改，并且除了事实规则名称现在将在组合命名空间中之外（根据 #921），它将完全按照 subninjas 的行为方式进行操作。 目前， subninja和include除了作用域变量和规则名称之外，基本上实现了相同的目标......

这个想法是生成器生成所有 .ninja 文件，因此它们可以写入相对于构建目录的路径。 组合由不同生成器生成的 ninja 文件是一个有趣的想法（听起来这就是您想要做的事情？），但目前还不支持。

正确， subninja和include之间的区别在于前者添加了范围，而后者没有。 用例是顶级忍者可以定义通用构建规则，例如 cc 引用变量，例如cflags ，并且每个子忍者可以将cflags设置为适合该目标的内容，并且可以是一次性的动作。 要查看示例，您可以运行 python misc/write_fake_manifests.py /tmp/foo` 将一堆使用此模式的 .ninja 文件写入 /tmp/foo。

这是有道理的，尽管我仍然没有看到太多好处（除了范围）。

将不同生成器生成的 ninja 文件组合起来是一个有趣的想法（听起来这就是你想要做的？）

确切地。 能够将 Ninja 本身包含为我的生成器的子模块，然后包含另一个 CMake 项目（配置为输出 Ninja 构建文件），然后为两者生成 Ninja 配置文件并将它们包含为subninja s _my_ 项目的build.ninja文件，以便能够像独立构建它们一样构建它们，但仍然允许我的项目使用它们的输出（以及它们的依赖关系图）以便一次构建整个项目.

如果这是有道理的。 我在生成器中看到的直接用例是它借鉴了 Tup 的一些概念（IIRC 影响了 Ninja 本身的一些设计决策），因为我可以包含 N 个子项目，它们都有自己的build.ninja文件，然后利用他们的图表来让我自动构建一个更大的依赖关系图。

我个人认为这会使subninja变得更加有用，尽管我认为这是一个潜在的重大变化。 但是，除非 1）我用补丁修改依赖项的build.ninja文件或 2）牺牲利用依赖项的依赖关系图的能力，否则我看不到解决方法。

想法？

怎么样：

subninja path/to/build.ninja relative path/to

缺席的relative默认为./ 。 如果生成器需要，这将使它不会中断，但仍会提供功能。

或者，按照其他 Ninja 构造的步骤，也许

subninja path/to/build.ninja
  relative = path/to

假设您在 .../foo 有一个项目，并且它有一个子目录 bar，并且 Ninja 具有您建议的相对路径逻辑。

如果您的构建系统想要将所有构建输出写入 /foo/obj，则 /foo/bar 中使用目录相对路径的 subninja 需要知道将其输出写入 ../obj/bar，因为这是该子目录中的文件。 因此，无论生成什么 build.ninja 文件，都必须已经知道全局路径层次结构，在这种情况下，使所有路径相对于在 bar/ 目录中的路径前添加 bar/ 实际上是相同的问题。

不过，也许有足够多的人在他们的源目录中编写构建输出，但上述内容并不重要。 我主要从那些想要更强大分离的人那里听到——比如那些向 Ninja 发送补丁来实现它的人，这样他们就可以在完全不相关的目录中使用构建输出构建 Ninja。

我不确定我是否理解。 子忍者，在我特别描述的用例中，通常不知道父忍者的结构（至少，不需要知道）。 不过，我敢肯定，有人可以找到他们这样做的案例。

我现在面临的问题是不使用我的生成器（100%）的依赖项（第三方库等）目前需要使用引导程序构建，并且每次都必须引导它们'被更新或更改等。我使用的大多数生成器都有输出到忍者配置的选项，但它们都是单独为该目录配置的（即相对于该目录）。

能够使用他们的配置和图表执行选择性重建将是巨大的。 目前，我不能这样做，因为subninja假定路径相对于构建目录。

Evan：我理解的方式是你会创建这样一棵树：

  subbuild1
  subbuild2

并且由于生成器通常支持将构建目录放在任意位置，因此在 subbuild1 中构建项目 1 和在 subbuild 2 中构建项目 2 应该可以工作。 然后在 builddir 中有一个顶级 ninja 文件， Qix-想要驱动构建子项目。

不相关：如果任何规则依赖于当前目录等于它们的构建目录（例如，如果规则剥离构建的工件或其他东西），则此relative功能还必须将 cwd 更改为其参数。