使用MaGeFror的大型C++项目有什么好的目录结构?

分离.h文件的.cpp并不总是一个好的解决方案。通常,当它用作库(include中的公共头和带有源代码的私有头)时,我会将它们分开。

如果它是一个库,那么这个结构就可以了。

lib/ (class implementations *.cpp .h)
include/ (class definitions *.h) <- Only those to be installed in your system
tests/ (main.cpp for quick tests)
doc/ (doxygen or any kind of documentation)

如果是申请

src/ (source for the application)
lib/ (source for the application library *.cpp *.hpp)
include/ (interface for the library *.h)
tests/ (main.cpp for quick tests) <- use cppunit for this part
doc/ (doxygen or any kind of documentation)

使用标志-i$(project_base)/include指定编译的包含路径

如果这是一个大项目,使用类似 autoconf/自动生成 或 小精灵 建造一切。有利于发展。

如果您有许多源文件,那么最好进一步细分源目录。例如,一个子目录用于应用程序的核心功能,一个子目录用于gui,等等。

src/core
src/database
src/effects
src/gui
...

这样做也会迫使您避免“模块”之间不必要的关系,这是良好和可重用代码的先决条件。

没有特定或必需的目录结构。

你可以随意设置。你的问题很容易解决。只需指示makefile查找子目录或将编译的对象放入子目录,而不只是使用当前目录。

您只需在makefile路径中使用:

%.o : %.cpp

替换为

bin/%.o : %.cpp

所以它会检查目录中的二进制文件 bin 存在等等,您可以将其应用于编译文件的位置。

有多种方法可以添加/删除/修改源文件和对象文件的路径。

看一看 gnu make manual ,具体章节 8.3文件名功能 ,之前的那个 8.2字符串替换和分析功能 。

你可以这样做:

从当前目录中的源文件列表获取对象列表:

OBJ     = $(patsubst %.cpp, %.o, $(wildcard *.cpp))

输出:

Application.o Market.o ordermatch.o

如果二进制对象在子目录中 箱子 但源代码在当前目录中,可以应用前缀 箱子 要生成对象文件,请执行以下操作:

OBJ     = $(addprefix bin/,$(patsubst %.cpp, %.o, $(wildcard *.cpp)))

输出:

bin/Application.o bin/Market.o bin/ordermatch.o

等等。

没有“好的目录结构”。选择一个你喜欢的结构并坚持下去。有些类似于将源文件(头文件和实现文件)放在 src/ 目录,所以项目的根目录只有makefile、readme和其他文件。一些类似于在 lib/ 目录下的unittests test/ 或 src/test/ ,文档 doc/ 等。

不过,我还没有听说有人将头文件和实现文件分成两个不同的目录。就我个人而言,我不太喜欢把文件分成目录。我通常将所有源代码放在一个目录中,所有文档放在另一个目录中。如果我仍然依赖好的搜索工具,就不需要复杂的目录结构。

make可以处理makefile所在目录与源目录不同的那种结构。唯一的问题是它将从makefile的目录中调用规则——编译器在编译某些子目录中的源代码时通常不会遇到问题。您不必在 #include s;只需使用编译器标志指定include路径(gcc -I 旗等)。

如果你在读之前没看过 Recursive Make Considered Harmful .

简短版本: 尽管递归make这个习惯用法很常见,但它并不是最理想的,而且随着项目越来越大、越来越复杂,它会变得越来越糟糕。提出了一种替代方案。

相关链接: What is your experience with non-recursive make?