让 GCC 在 ./ 之前查找 <dir> 中的标头

Question

背景：

我正在为一个嵌入式项目构建一个测试环境。由于它是一个嵌入式项目，它会尝试访问硬件寄存器，例如ADC 结果、定时器设置、中断标志...

这些寄存器由 Halcogen（它是一个 TI 处理器）自动实现，定义为指向特定地址。

    #pragma system_include

    #ifndef __REG_FLASH_H__
    #define __REG_FLASH_H__

    /* USER CODE BEGIN (0) */
    /* USER CODE END */

    #include "sys_common.h"

    typedef volatile struct flashWBase
    {
        uint32 FRDCNTL;       /* 0x0000 */
        uint32   rsvd1;       /* 0x0004 */
        .
        .
        .
        uint32 EESTATUS;      /* 0x031C */
        uint32 EEUNCERRADD;   /* 0x0320 */
    } flashWBASE_t;

    #define flashWREG ((flashWBASE_t *)(0xFFF87000U)) //<--- This one

    #endif

我尝试的解决方案：

为了在 MinGW Win7 机器上编译和运行此代码，需要重新定义这些特定地址以指向可观察和可变变量。我有一个分析源代码的 Python 脚本；在包含以下内容的公共目录中使用相同的名称创建新的头文件：

    #ifndef _COMMON_INCLUDES_REG_FLASH_H_
    #define _COMMON_INCLUDES_REG_FLASH_H_

    #include "..\..\W2_Library\Halcogen\Include\reg_flash.h" //<--- original Halcogen header

    #undef flashWREG
    flashWBASE_t _flashWREG;
    #define flashWREG (&_flashWREG)

    #endif

我曾多次尝试使用-I-、-I<dir> 和-iquote 来重定向包含的标头，使用已弃用的-I- 使GCC 忽略. 目录。但是，我宁愿将我的 Common 文件夹放在 . 之前，而不是一起忽略。添加-I. 似乎不是一回事，我感觉它会扩展到源代码目录并且不会保持“相对”，因为 GCC 会像原来的 . 那样深入研究包含树.

让我的 Python 脚本克隆整个标头，只用变量替换硬件地址，这可能是一个解决方案。然而，仅仅在单独的头文件中重新定义寄存器定义确实不太容易出错。

问题：

还有其他方法可以改变搜索顺序吗？ 我已经阅读了几个关于-I- 的问题，但没有一个关于你如何解决这种行为的答案。 This question 非常接近，但与那个用户不同，我没有使用预编译的头文件。

以上有一些假设，如有错误请指正！

Answer 1

您遇到的问题是#include "..." 而不是#include <...>

对于普通的 C 编译器，使用 " 形式总是在与当前文件相同的目录中搜索，然后 然后 在 -I 设置的包含路径中查找。如果您想在查看当前文件的目录之前先搜索其他位置，则没有简单的方法。

你可以使用gcc的-I-来禁止在当前文件的目录中搜索，并添加其他目录只用于"包含文件（不适用于<>），但如果你使用它，没有办法恢复在当前文件目录中搜索的行为。

你可以试试这样的：

-ICommon -I. -I- -Iwhatever

这将首先在Common 中搜索"，然后在当前工作目录中，然后在whatever（以及正常路径的其余部分）中搜索，而<> 将从whatever 开始。不幸的是，它永远不会在当前文件的目录中搜索，如果它与当前工作目录不同。

-I- 也已被弃用，因此可能很快就会消失。