【发布时间】：2015-11-14 01:46:00
【问题描述】：
在一个具有目录树结构文件的大型项目中，最好在源文件中包含相对路径，还是只包含头文件并通过 Makefile 指示编译器在哪里找到它？
有首选方式吗？
例子：
#include "../path/to/file.h"
对比
#include "file.h"
gcc -I../path/to
我相信第一种情况可能更具可读性，而第二种方法可以无缝移动文件...
【问题讨论】：
【发布时间】：2015-11-14 01:46:00
【问题描述】：
第二种方法效率更高，因为您不必每次要使用此文件时都重写路径。
让我们举个例子。
您想构建一个包含一些有用功能的库。 然后你在一个项目上工作，你需要一些库的功能，而不是全部。 因此，您选择将这些文件中的一些 mv 放入您的项目文件夹中。
这样，路径可能会不一样，如果您选择在 Makefile 中包含路径，您将不必重写所有内容。
正确编码您的 Makefile，让您拥有多个 $(PATH)，这在处理需要多个二进制文件的大型项目时非常有用。
我试图尽可能地清楚，但我真的认为，在我看来，Makefile 是一个非常强大的工具，可以尽最大努力使项目开发更容易。
【讨论】：
-
谢谢。我同意你的观点，make 是一个非常强大的工具。但是您没有提到显式路径可能有用的地方，我相信它们不是“全错”
这取决于。对于项目中的包含文件，提供相对路径可能很有用，因为子目录是另一个结构元素，您不必关心相同的文件名（主要用于 C++，因为 C 不支持自定义命名空间)。
对于外部路径（例如其他项目），您应该明确使用第二种方法。可能只是到该结构的根源。类似于asm/byteorder.h。
无论如何，如果使用显式路径（在源文件中），您应该确保它们有良好的文档记录，并且对源文件的任何更改都进行了跟踪。 （经常有常用的子目录，比如config等不会变）。
强烈建议：始终使用项目根目录作为工作目录。所有显式相对路径都来自此根。这样您就可以避免出现问题的父 (..) 路径。
终极规则是不要使用跨越项目根目录的显式路径。
但是，没有其他一般规则。实际布局往往取决于个人喜好。如果目录结构经过深思熟虑，我更喜欢显式路径。
【讨论】：
-
这个。没有一般规则，但应该考虑包含文件的“命名空间”。如果您没有子目录，则很容易与其他名称发生冲突。但这都是政策，有很多方法可以解决这个问题。不过就个人而言，我会远离带有
".."的路径。这会使代码重用变得更加困难。此外，有理由永远不要使用""，但始终使用<>，但同样，这是偏好和政策，没有硬性规则可以帮助您。 -
我认为这是更有经验和有用的答案。 @Prof.Falken 为什么我不应该为包含使用引号？
-
@Prof.Falken：我想我在第一段就说过了。但是由于 C 本身没有命名空间，所以您仍然需要关心标识符。对于
..，我添加了一些内容。对于""与“”，我不同意。<>用于“外部”/系统包含，而""用于项目包含。我认为区别很明显。 （但我同意这里的标准应该更加清晰/严格）。 -
@kometonja，好吧，一方面，带有
""，引号，文件必须与源位于同一目录中。但是如果你有<>，括号，你可以将它们放在与源相同的目录中（通过用编译器指出它们所在的位置，例如-I用于gcc）和后来决定将包含文件放在其他地方。现在，如果你有引号，你必须也更新所有包含它们的 C 文件。另外，如果我们很挑剔，引号实际上很奇怪。见stackoverflow.com/a/77092/193892。 C 标准由编译器供应商决定如何使用。 -
@Prof.Falken：“文件必须与源文件位于同一目录中”否：standard 将两者的搜索策略留给了实现。有时最好有两种不同的搜索策略。
gcc -I不区分两个版本，顺便说一句。关于怪异："是一个普通的字符串文字分隔符。完美的文件名。<>, OTOH 在 C++ 中用于模板 - 与文件名关系不大。