C言語でMakefileの実行時、インクルードしているはずの変数が"undeclared"となる原因

Question

###前提・実現したいこと
組み込み系のソフト開発で、GNUツールチェーンでの開発環境構築を試みています。
CYPRESSのアプリケーションノートを参考に、Makefileを記述しCソースのコンパイルをしようとしているのですが、インクルードしたヘッダファイル内で#defineされているはずの変数が、undeclaredでエラーになります。
なお問題の変数は、EEPROM領域のデータを読み出して変数として定義したものです。
EEPROM領域というのは、マイコンメモリのflash領域の一部をEEPROMとみなしてデータを格納している部分という大雑把な認識なのですが、不正確ならすみません。

申し訳ありませんが対象のプロジェクトは外部に出せないものなので、以降それをイメージした簡易なプロジェクト例で説明させていただきます。また、この簡易プロジェクトだと同様のエラーを再現できていませんので、あくまでイメージとさせてください。

###問題の内容

makeでヘッダファイルを見つけられていないなら、エラー内容は

source_b/Ret.c:1:10: fatal error: 'header_a.h' file not found
#include "header_a.h"
         ^
1 error generated.

というようなものになると思うのですが、実際には

source_b/Ret.c:3:12: error: `HEADER_A' undeclared (first use in this function)
        int x = HEADER_A * 2;
                ^
1 error generated.

というエラーが出ています。

このように、Makefileでインクルードされているヘッダ自体は見つけられているようなのに、そのヘッダ内で#defineされている変数は探せていないというのは、どういう場合が考えられるのでしょうか？

###再現のための簡易プロジェクト
ディレクトリ構成

TestProject┬─/header_a/─header_a.h
           │
           ├─/source_a/─Main.c
           │
           ├─/source_b/─Ret.c
           │
           ├─/dep/─Main.o.d
           │       └─Ret.o.d
           │
           └─Makefile

CC = gcc
AS = as
LD = ld -v
CP = gobjcopy

PROJECT = test-mf

SRC = $(shell find source_a source_b -name *.c)
ASRC = $(shell find source_a source_b -name *.s)
INCDIR = -I./header_a
OBJS = $(SRC:.c=.o) $(ASRC:.s=.o)

OPT = -O0

CPFLAGS+= -Wall
CPFLAGS += -MD -MP -MF ./dep/$(@F).d

all:ROM
ROM: ASFLAGS += eedefsym Debug_RAM=0
ROM: clean $(OBJS) $(PROJECT)_rom.elf $(PROJECT)_rom.hex
ROM: $(PROJECT)_rom.bin

%.o : %.c
	@echo "--compiling--"
	$(CC) -c $(CPFLAGS) -I . $(INCDIR) $< -o $@

%.o : %.s
	@echo "--assembling--"
	$(AS) $(ASFLAGS) $< -o $@

%rom.elf: $(OBJS)
	@echo "--linking--"
	$(CC) $(OBJS) -o $@

Main.c

int main(void){
    extern int ret_a(void);
    int a = ret();

    return 0;
}

Ret.c

#include "header_a.h"
int ret_a(void){
    int x = HEADER_A * 2;
    int y = HEADER_B * 2;
    return x + y;
}

header_a.h

#define HEADER_A eeprom_data[0x01] * 10 //EEPROM領域のデータ
#define HEADER_B eeprom_data[0x02] * 10

###補足情報(言語/FW/ツール等のバージョンなど)
C言語
GNUツールチェーン

Answer 1

source_b/Ret.c:3:12: error: 'HEADER_A' undeclared (first use in this function)

return HEADER_A * 2;

このエラーが出ているならHEADER_Aが#defineされていないか、#undefされているか、プリコンパイルヘッダ(.pch)が更新されていないかのいずれかだと思います。gccのプリコンパイルヘッダについてはよく知らないので、最初の可能性に着目すると#if/#ifdef/#ifndef/#else/#elif/#endifなどのスイッチの綴りミスや条件間違い等々の影響によって#define HEADER_A ...の行がスキップされているか#include自体がスキップされているといった原因が考えられると思います。

まずは#define HEADER_A ...の直前に#error defining HEADER_Aという行を挿入してコンパイルすれば、このヘッダーの該当位置が本当に生きているか(実際にincludeされていて#ifなどででスキップされてないか）が確実にわかるのではないでしょうか。このエラー(defining HEADER_A)が出なければスキップされているのは確実と思えるので前述したコンパイルスイッチによってどの部分がスキップされているか確認すべきと思います。

Comments

[minato_hy]

なるほど、Makefileの記述の問題ではなく、ヘッダファイル側の問題かもしれないということですね。週明けに試させていただきます。

[minato_hy]

#error行を追加しmakeを実行したところ、確かにdifiningのエラーは出なかったのですが、同時にHEADER_Aがundeclaredだというエラーも出なくなり、Ret.oが生成されてしまいました。
これは、どう考えればいいのかちょっとよく解らないです。

[KSwordOfHaste]

ということはどこか別の場所で#defineされていたのでしょうね。そちらの定義でコンパイルできたということなのでしょう。makefileはソースやオブジェクトなどのファイルの依存関係と更新日付で適切なアクションを取るのですがファイルを書き換えてうまくいったなら「どこかに更新日付が不適切になっていてそれがたまたま解消されたから」といった原因かも知れません。
詳しくはmakefileの全容と全ての依存ファイルの状態をみて調べるしかないと思います。
蛇足ですが、なぜうまくいったのかは明確に原因をおさえておいた方がよい気がします。原因がわかればどこかにあるかも知れないミスに気づけることがあり、それが後々のトラブル防止につながるからです。

Answer 2

makeファイルの問題ではありません。

eeprom_dataを配列宣言する前に使用しているので、警告が
出ているものかと思います。

#define 文ですが、だだの文字列置き換えです。

int ret_a(void){
    return eeprom_data[0x01] * 10  * 2;
}

Comments

[minato_hy]

解りにくくてすみません、EEPROMにアクセスする関数がコンパイラで用意されていたりすると思うのでeeprom_dataはそれだと思ってください。
それともEEPROMにアクセスしている場合、Makefileでコンパイラの指定以外になにか特別な記述が必要なのでしょうか？

[nagaetty]

EEPROMのアドレス情報が定義されている値が代入されている、定義がheaderにあったりするかと思います。もしくは、Linkerで後で割り当てを定義するのですが。ヘッダのソースを眺めてみることをお勧めします。

[minato_hy]

確認してみます。ただ、EEPROMのアドレス情報の定義などが問題だった場合、この場所で「変数が`undeclared`だ」というエラーが出るのではなく、別の場所で出るか別のエラーになる気がするのですが。私の勘違いか、もしくはコンパイラによって違ったりするのでしょうか。

[nagaetty]

エラーができるのは、型宣言がないからだと思います。
(unsigned int *) eeprom_data = 0xf3420000 ;
のような宣言定義があって、代入式がこないとエラーになるかと思います。

[nagaetty]

CYPRESSのアプリケーションノートを参照しましたが、makefileにTRGET指定がないので、メモリマップが存在しないことになっているようなので、エラーになっているものと思います。
EEPROM領域は組み込みターゲットで電源をOFFにしているときにもデータを保持しているメモリエリア。（JTAGやROMライタなどで書込みを行う領域）組込みのＣ開発では、プログラム領域、データ領域とワークメモリ領域を明確に割り当てて作成します。

[minato_hy]

問題のプロジェクトではターゲットもEEPROMの各種定義もちゃんと設定されていました。
また、上の方のアンサーへのコメントで書いたように、#error行を追加するとコンパイルが通るというよく解らないことが起こっています。