编译时是否可以指定相对于用户当前目录的#include文件路径？

Question

我知道可以指定#include相对于文件所在目录的文件路径（作为绝对文件路径），也可以指定相对于$PATH系统变量中任何目录的文件路径。编译程序时，有没有办法相对于用户的当前目录来指定它？假设我具有以下文件结构：

|--dir_a/
|  |--a.c
|  |--a.h
|--dir_b/
|  |--b.c
|  |--b.h
|--makefile

现在，假设我要从中#include获取文件。使用的位置，可以这样写：dir_a/a.hdir_b/b.hdir_b/b.h

#include ../dir_a/a.h

但是，在我看来，这种方法存在一个重大缺陷，因为它会对文件之间的位置进行硬编码，这意味着重新定位文件将需要更新包含该文件的所有位置的文件路径。

使用绝对文件路径可以避免此问题，但可以硬编码项目在文件系统中的位置，这似乎是一种不好的做法。

最后，使用<>标签指定文件路径也不可行，因为我无法假定该项目将在$PATH变量中列出。

因此，我想做的是能够指定相对于用户从中进行编译的路径（甚至从makefile的位置进行编译）。在上面的示例中，这将使我使用以下语句来#include dir_a/a.hfrom dir_b/b.h：

#include dir_a/a.h

我认为这将是理想的解决方案。这将使这些#include语句更加一致并且更易于遵循，并且避免了我上面列出的缺点。是否有可能以任何方式做到这一点，例如 与编译器标志或什么？我正在gcc用作编译器。

Answer 1

如果您一直使用<>includes，那么-Imakefile 中的选项应该足够了。目录布局仅显示一个makefile, 在父目录中。那可以用

-Idir_a -Idir_b

在编译器选项中，.c 文件可以做

#include <a.h>
#include <b.h>

引用的包含的问题之一是它们与其他编译器的行为可能不同，如和之间有什么区别？#include <filename>#include “filename”（标准不够明确）。使用 gcc 扩展可能不会改善这种情况。