Make GCC look for headers in <dir> before ./

Question

Background:

I am putting together a test environment for an embedded project. Since it's an embedded project it tries to access hardware registers e.g. ADC results, timer settings, interrupt flags...

These registers are implemented automatically by Halcogen (it's a TI processor), as defines pointing to specific addresses.

    #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

My attempted solution:

In order to compile and run this code on a MinGW Win7 machine these specific addresses need to be re-defined to be pointing to observable and mutable variables. I have a Python script that analyzes the source code; creating a new header file using the same name in a common directory containing:

    #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 have made many attempts using -I-, -I<dir> and -iquote to redirect inclusion of the headers getting farthest using the deprecated -I- to make GCC ignore the . directory. I would however rather have my Common folder precede the . than ignoring all together. Adding a -I. does not seem to be the same thing, I get the feeling it expands to the directory of the source code and doesn't stay "relative" as GCC delves deeper into the inclusion tree like the original . do.

Letting my Python script clone the entire header, replacing only the HW address with a variable, could be a solution. Just redefining the register defines in a separate header does however feel less prone to break.

Question:

Is there any other ways to alter the search order? I have read several questions about -I- but none has really had any answers as to how you get around the behaviour. This question is pretty close but unlike that user, I am not using precompiled headers.

There are a few assumptions above and please correct me if they are wrong!

Answer 1

The problem you are having is with #include "..." as opposed to #include <...>

With a normal C compiler, using the " form always searches in the same directory as the current file, and then looks in the include path set by -I. If you want to search somewhere else before looking in the current file's directory, there's no easy way to do it.

You can use gcc's -I- to inhibit searching in the current file's directory, and add other directories to use only for " include files (not for <>), but if you use that, there's no way to get back the behavior of searching in the current file's directory.

You can try something like:

-ICommon -I. -I- -Iwhatever

This will search for " includes first in Common, then in the current working directory, then in whatever (and the rest of the normal path), while <> will start in whatever. Unfortunately, it will never search in the current file's directory, if that is different from the current working directory.

-I- is also deprecated, so may go away soon.