目标文件生成和使用 makefile 进行链接的最佳实践 - C++

Question

背景

我刚刚开始在 LINUX 上进行 C++ 编程。 在我的上一个问题中，我询问了在大型应用程序中使用 makefile 的最佳实践。 “SO”用户建议阅读 Miller 关于递归 makefile 的论文并避免 makefile 递归（我正在使用递归 makefile）。

我跟随 miller 创建了一个如下所示的 makefile。 以下是项目结构

root
...makefile
...main.cpp
...foo
......foo.cpp
......foo.h
......module.mk

我的 makefile 如下所示

#Main makefile which does the build

CFLAGS =
CC = g++
PROG = fooexe

#each module will append the source files to here
SRC :=

#including the description
include foo/module.mk

OBJ := $(patsubst %.cpp, %.o, $(filter %.cpp,$(SRC))) main.o

#linking the program
fooexe: $(OBJ)
    $(CC) -o $(PROG) $(OBJ)

%.o:
    $(CC) -c $(SRC)

main.o:
    $(CC) -c main.cpp

depend:
    makedepend -- $(CFLAGS) -- $(SRC)

.PHONY:clean
clean:
    rm -f *.o

这是 foo 目录中的 module.mk 。

SRC += foo/foo.cpp

当我运行 make -n 时，我得到以下输出。

g++ -c  foo/foo.cpp
g++ -c main.cpp
g++ -o fooexe  foo/foo.o main.o

问题

• 我应该在哪里创建对象(.o) 文件？ 单个目录中的所有目标文件还是其自己的模块目录中的每个目标文件？ 我的意思是哪个是生成 foo.o 的最佳位置？ 它是在 foo 目录还是根目录中（我的示例在根目录中生成）？
• 在提供的示例中，g++ -c foo/foo.cpp 命令在根目录中生成 .o 文件。 但是当链接（g++ -o fooexe foo/foo.o main.o）时，它正在寻找foo/foo.o。 我该如何纠正这个问题？

任何帮助都会很棒

Answer 1

• 我应该在哪里创建对象（.o）文件？ 单个目录中的所有目标文件还是其自己的模块目录中的每个目标文件？ 我的意思是哪个是生成 foo.o 的最佳位置？ 它是在 foo 目录还是根目录中（我的示例在根目录中生成）？

我发现将对象文件本地化到模块级目录下的单独目录中更容易调查失败的构建。

foo
    |_ build
    |_ src 

根据项目的大小，这些目标文件被分组以形成更高级别的组件等等。 所有组件都进入主构建目录，主应用程序可以在该目录中运行（具有所有依赖库等）。

• 在提供的示例中，g++ -c foo/foo.cpp 命令在根目录中生成 .o 文件。 但是当链接（g++ -o fooexe foo/foo.o main.o）时，它正在寻找 foo/foo.o。 我该如何纠正这个问题？

使用：

 g++ -o fooexe  foo.o main.o

Answer 2

SCons +1。
我也在使用 SCons。 它会为您扫描依赖项，并且仅在源发生更改时才进行重建，因为它使用加密哈希和而不是时间戳。

在我的 SCons 中，构建对象位于与源并行的目录中（以启用多个构建，例如 32 位和 64 位的组合、发布和调试）：

src
.build
  linux
    i686
      debug
      release
    x86_64
      debug
      release

Answer 3

对于对象和其他生成的临时文件，我将它们放在与源完全分开的目录中（即，在排除备份和修订控制的目录下）。 在项目或 makefile 中进行设置可能会稍微麻烦一些，但它可以节省打包源代码的时间，并且更容易进行干净的备份和修订控制。

我为目标文件创建一个与源的子目录结构相匹配的子目录结构。 通常，我的每个库和程序都有一个单独的子目录。

此外，我还使用多个编译器（和版本）和多个操作系统，因此我将在每个编译器（具有较新版本的标准库和供应商库）的目录下重现目标文件目录结构，以防止目标文件不匹配包含的头文件版本。

Answer 4

你能为自己做的最好的事情就是使用比 Make 更好的东西。 SCons 是我在 POSIX 系统上选择的工具。 Boost 还有一个非常灵活的构建工具，但我很难理解它。

哦，如果您想使用 make，请继续构建递归 makefile。 这确实没什么大不了的。 在过去的三年里，我使用了大量的递归 makefile 参与了一个巨大的项目，而且效果很好。