Question

在一个包含目录树结构文件的大型项目中，最好是在源文件中包含相对路径，还是只包含头文件并通过Makefile指示编译器在哪里找到它？
有没有首选方式？

示例：

#include "../path/to/file.h"

VS

#include "file.h"
gcc -I../path/to

我相信第一种情况可能更具可读性，而第二种方法可以无缝移动文件......

Answer 1

第二种方法效率更高，因为每次要使用此文件时都不必重写路径。

让我们举个例子。

您想要构建包含一些有用功能的库。然后，您在一个项目上工作，您需要一些库函数，而不是所有函数。所以你选择将这些文件中的一些文件放到项目文件夹中。

这样，路径可能不一样，如果您选择在Makefile中包含路径，则不必重写所有内容。

正确编码你的Makefile，让你有几个$（PATH），这在处理需要多个二进制文件的大型项目时非常有用。

我试图尽可能地清楚，但我认为，我认为Makefile是一个非常强大的工具，可以最大限度地利用它来使项目开发更容易。

Answer 2

这取决于。对于项目中的包含文件，给出相对路径可能很有用，因为子目录是另一个结构元素，您不必关心相同的文件名（主要用于C ++，因为C不支持自定义命名空间））。

对于外部路径（例如其他项目），您应该明确使用第二种方法。可能只是该结构的根源。与asm/byteorder.h类似。

无论如何，如果使用显式路径（在源文件中），您应该确保它们有详细记录，并且跟踪源文件的任何更改。（常见的子目录，如config等，不会改变）。

强烈建议：始终将项目根目录用作工作目录。所有显式相对路径都来自此根。这样您就可以避免出现问题的父（..）路径。

最终规则不是使用跨项目根的显式路径。

但是，没有其他一般规则。实际布局通常取决于个人喜好。如果目标结构经过深思熟虑，我更喜欢显式路径。