具有公共源文件和子项目的适当项目组织

Question

我有一个直接的C项目，它使用单个顶级makefile和对模块的递归调用将几个不同的相互关联的模块构建到单个映像中。这一切都很好，虽然我知道它没有使用最好的结构。我现在需要重新构建它，因为项目有一些变化，我想“正确”。另外，我发现我在模块中使用了一些常用代码，现在只是复制到每个模块中，所以我也想修复它。

更复杂的是我正在使用Subversion，并且正在使用的公共代码存储在项目的单独repo中，所以我不能只导入使用过的每个文件。

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

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

Common将是另一个repo中具有公共源文件的文件夹的外部，并且每个模块中的makefile将在本地构建中间对象文件（这是必需的，因为每个模块编译方式不同，因此公共文件不是常见二进制文件）然后将其最终二进制文件放在共享输出目录中，以便将顶级makefile组合成单个最终图像。

1. 这是一个合理的结构用于make来处理吗？
2. 模块1使用可能稍后关闭的第三方库。它应该是module1的子目录，还是它应该是共同的（难以与subversion一起使用，除非我把它混合到另一个repo上的文件夹中），还是应该在build下添加为另一个目录？
3. 模块2编译为静态库供模块3使用。模块3的makefile是否应该明确知道模块2，或者头文件应该在公共目录中（库是否已经在输出目录中）？
4. 此项目需要为所有模块设置其他常见定义，这些定义通常位于公共目录的头文件中，但由于该目录来自外部的subversion，我的其他选项是什么？这样做？

Answer 1

首先，这些设计问题中的一些是品味和习惯问题，关于它们的争论可能会接近宗教战争。

其次，您的common目录命名不佳，因为它专门用作来自其他存储库的代码存储（这是一件好事），而不是作为多个模块共享的所有源的地方（不同的好事）。因此，我建议您添加另一个目录，例如build/headers/，用于多个模块共有的标头，但存储在您自己的存储库中。

1. 是的，一旦你添加了标题/。
2. module1 /的子目录是一个好地方;如果其他模块没有使用它，那么他们没有理由看到它。
3. headers /就是为此而制作的。把标题放在那里。模块3没有了解更多有关模块2实现的业务。
4. 同样，header /是他们的地方。