c语言 - 让 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_LibraryHalcogenIncludereg_flash.h" //<--- original Halcogen header
    #undef flashWREG
    flashWBASE_t _flashWREG;
    #define flashWREG (&_flashWREG)
    #endif

我已经多次尝试使用-I-、-I<dir>和-iquote来重定向包含最远的标头，使用不推荐使用的-I-来使GCC忽略.目录。然而，我宁愿将Common文件夹放在.之前，也不愿将它们一起忽略。添加-I.似乎不是一回事，我感觉它扩展到了源代码的目录，并且不像最初的.那样，随着GCC深入到包含树中，它不会保持"相对"

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

问题：

有其他方法可以改变搜索顺序吗？我读过几个关于-I-的问题，但没有一个能真正回答你如何避开这种行为。这个问题很接近，但与那个用户不同的是，我没有使用预编译的头。

上面有几个假设，如果它们是错误的，请纠正我！

Answer 1

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

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

您可以使用gcc的-I-来禁止在当前文件的目录中搜索，并添加其他目录以仅用于"包含文件（不用于<>），但如果使用该目录，则无法恢复在当前文件目录中搜索的行为。

你可以试试这样的东西：

-ICommon -I. -I- -Iwhatever

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

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