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

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

更复杂的是，我使用的是Subversion，所使用的公共代码存储在项目的一个单独的repo中，因此我不能只导入所使用的每个文件

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

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

这是一个合理的结构来处理make吗

模块1使用第三方库，以后可能会被关闭。它应该是module1的子目录，还是应该是公共目录（subversion很难做到，除非我将它混合到另一个repo上的文件夹中），还是应该作为构建中的另一个目录添加

模块2编译为静态库，供模块3使用。模块3的makefile是否应该明确知道模块2，或者头文件是否应该在公共目录中（库已经在输出目录中）

本项目需要为所有模块设置其他通用定义，这些定义通常位于公共目录中的头文件中，但由于该目录来自subversion外部，我的其他选项是什么

---

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

其次，您的

common

目录命名不好，因为它专门作为另一个存储库中代码的存储（拥有它是件好事），而不是作为多个模块共享的所有源的位置（拥有它是另一件好事）。因此，我建议您添加另一个目录，例如

build/headers/

，用于多个模块共用但存储在您自己的存储库中的头

是的，一旦你添加了标题/。

模1/的子曲面是它的好位置；如果其他模块不使用它，他们没有理由看到它。

标题/字面上就是为这个而做的。把收割台放在那里。模块3没有必要知道更多关于模块2实现的信息。

同样，headers/是它们的位置。

---

您有多个模块，共享一个公共源文件，每个模块以不同的方式编译，然后链接二进制文件。这听起来一点也不好，我想还有更多的故事。@Beta他们只共享一些文件，比如日志记录函数或CRC处理函数。每个模块都在虚拟机中独立运行，所有虚拟机都绑定到一个映像中以加载到嵌入式设备上。这一切都很好，但它不仅仅是公共文件夹中的头文件，也是源文件。

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