我正在查看 AVR 端口的 FreeRTOS 演示项目。 Makefile 通过“-I”指令具有指向 RTOS 源文件所在目录的路径。但是，在项目的 main.c 模块中，#include 没有提供任何这样的路径：
#include "FreeRTOS.h"
所以我无法理解是只有链接器需要“-I”指令才能找到目标文件？这是否也意味着一旦文件被编译为目标代码，对于 GCC，如果它知道在哪里查找，它们本质上就位于同一个文件夹中？
我之所以感到困惑，是因为我以前曾见过这样的 #include 语句：
#include <avr/io.h>
如果 GCC 已经知道 io.h 的位置，为什么还要在其前面加上 "avr" 部分？
【问题讨论】：
-I 告诉编译器搜索该路径以查找头文件。这就是#include "FreeRTOS.h" 不需要路径的原因。如果没有-I，那么您需要将完整路径放在#include 中（这是不好的做法）。
当我们说
#include <foo/bar.h>
编译器通常会在一个名为foo 的目录中查找名为bar.h 的文件，该目录是它配置为查找头文件的位置之一。例如，标准头搜索路径通常包含 `/usr/include'，因此如果存在文件 'bar.h'，则会在 '/usr/include/foo' 中找到它。
如果你像这样使用-I 开关：
-I /usr/include/foo
你也可以写
#include <bar.h>
因为您已将目录 foo 包含在编译器的头文件搜索路径中。
但是，如果 foo 是某种库或模块，则使用包含子目录 foo 的 #include 的变体可能更具表现力，而不是操纵标头搜索路径，这样您就不会必须。
郑重声明，-I 开关对链接行为没有直接影响。
顺便说一句，变种
#include "foo/bar.h"
通常表示目录foo 中的文件与源文件位于同一目录中。但是，现代编译器似乎也将搜索头路径应用于这些指令。我不确定这是基于标准的行为，还是只是编译器编写者试图猜测我们的意图。
【讨论】：