我至少可以想到一些用例或场景:
- 构建多个示例程序的“示例”配置。
- 具有客户端程序和主机程序的项目。
- 具有一个主程序和一些相关实用程序(例如:gcc)的项目。
更一般地说,如果项目有多个具有相同或相似依赖集的输出可执行文件,那么一次构建它们可能是有意义的。用户决定运行哪个可执行文件比弄清楚如何使 DUB 创建他们想要的可执行文件更容易(他们可能不是熟悉 DUB 的 D 开发人员)。作为一名 D 开发人员,这对我来说也很方便,因为我可以运行更少的构建命令来获得我想要的全部内容。
例如,我可能有这样的项目布局:
dub.json
.gitignore
source/common/foo.d (Code called by all examples)
source/examples/simple_example.d (Build input with main function)
source/examples/complex_example.d (Build input with main function)
source/examples/clever_example.d (Build input with main function)
bin/simple_example.exe (Output executable)
bin/complex_example.exe (Output executable)
bin/clever_example.exe (Output executable)
另一个项目可能如下所示:
dub.json
.gitignore
source/common/netcode.d (Code called by all programs)
source/common/logic.d (Code called by all programs)
source/executables/host-daemon.d (Does privileged things for the server)
source/executables/server.d (Unprivileged network endpoint)
source/executables/client.d (Queries the server)
bin/host-daemon (Output executable)
bin/server (Output executable)
bin/client (Output executable)
在任一项目中,我都希望通过一次 DUB 调用来构建所有可执行文件。理想情况下,由于输入和输出的相互关联性,这一切都将通过一个 dub.json 文件进行管理。
似乎subPackages可能能够做到这一点,但从一个 dub.json 文件管理它“通常不鼓励”:
子目录 /component1 和 /component2 然后包含普通包,可以从外部项目中称为“mylib:component1”和“mylib:component2”。要引用同一存储库中的子包,请使用“*”版本说明符。
也可以在根包文件中定义子包,但注意是
generally discouraged
将多个子包的源代码放在同一个源文件夹中。这样做可能会导致对“依赖项”部分中未明确说明的子包的隐藏依赖项。这些隐藏的依赖关系可能会导致与某些可能难以理解的构建模式或依赖关系树相结合的构建错误。
如上所述,DUB 可以一次构建多个可执行文件吗?如果可以,最推荐的方式是什么?为什么?