c - 具有公共(public)源文件和子项目的正确项目组织

Question

我有一个直接的 C 项目，它使用单个顶级 makefile 和对模块的递归调用将几个不同的相互关联的模块构建到单个镜像中。这一切都工作正常，尽管我知道它没有使用最好的结构。由于项目发生了一些变化，我现在需要重组它，我想“正确”地做它。此外，我发现我在模块中使用了一些通用代码，这些代码现在只是复制到每个模块中，所以我也想修复这个问题。

更复杂的是，我正在使用 Subversion，并且正在使用的通用代码存储在与项目不同的存储库中，因此我不能只导入使用的每个文件。

这是我想使用的结构，但我不完全确定如何编写 makefile 来实际使用它(但如果需要，我可以在另一个问题中处理它)。

build
 +  common
 |   +  lib1
 |   +  lib2
 +  module1
 |   +  obj
 +  module2
 |   +  obj
 +  module3
 |   +  obj
 +  output

Common 是另一个存储库中具有公共(public)源文件的文件夹的外部，每个模块中的 makefile 将在本地构建中间目标文件(这是必需的，因为每个模块编译方式不同，因此公共(public)文件不是通用二进制文件)，然后将其最终二进制文件放入共享输出目录中，以便顶层 makefile 组合成单个最终镜像。

1. 这是一个供 make 处理的合理结构吗？
2. 模块 1 使用第三方库，该库可能稍后会被更换。它应该是 module1 的子目录，还是应该是通用的(很难用 subversion 做到，除非我将它混合到另一个存储库上的文件夹中)，或者应该将其添加为 build 下的另一个目录？
3. 模块 2 编译为静态库供模块 3 使用。模块 3 的 makefile 是否应该明确了解模块 2，或者头文件是否应该位于公共(public)目录中(库已位于输出目录中)？
4. 这个项目需要为所有模块设置其他通用定义，这些定义通常位于公共(public)目录的头文件中，但由于该目录来自 subversion 外部，我的其他选项是什么这样做？

Answer 1

首先，其中一些设计问题涉及品味和习惯问题，有关这些问题的争论可能接近宗教 war 。

其次，您的 common 目录命名不当，因为它专门用于存储其他存储库中的代码(这是一件好事)，而不是作为所有共享源的位置由多个模块组成(这是一个不同的好事)。因此，我建议您添加另一个目录，例如 build/headers/，用于存储多个模块共用但存储在您自己的存储库中的 header 。

1. 是的，一旦添加标题/。
2. module1/的子目录是一个好地方；如果其他模块不使用它，它们就没有理由能够看到它。
3. headers/就是为此而设计的。将标题放在那里。模块 3 没有必要比模块 2 的实现了解更多。
4. 同样， headers/是放置它们的地方。