このメイクファイルはすべてのオブジェクトに適用されないのはなぜですか？

Question

このメイクファイルは私が期待どおりに動作しません。現在のディレクトリとサブディレクトリにある各.cファイルの.oファイルをビルドして、静的ライブラリに配置します。ただし、最初のファイルまたは2番目のファイルの後に$（INCS）の適用を停止します。 2つ目の.oファイルをビルドしようとすると、ビルド行に-Iパスが表示されず、そこにヘッダーファイルが見つからないという不満があります。物事を簡素化するために名前が一般化されています。私はWindows XPでcygwinを使用しています。私はcygwinツリーの下にないARMクロスコンパイラを使用しています。私はこのメイクファイルを回答hereに基づいています。 .cファイルは約2ダースしかないので、このように依存ファイルを作成するオーバーヘッドは大きな問題ではありません。

# Project specific options 
CC = my-cross-gcc 
INCS := -I. -Iinc 
INCS += -Imy/inc/path 

CFLAGS := -Wall -fPIC -static -cross-compiler-specific-options 

OUT := bin/libmylib.a 

MKDIR:=mkdir -p 

### Generic C makefile items below: 

# Add .d to Make's recognized suffixes. 
SUFFIXES += .d 

NODEPS:=clean 
#Find all the C files in this directory, recursively 
SOURCES:=$(shell find . -name "*.c") 

#These are the dependency files 
DEPFILES:=$(patsubst %.c,%.d,$(SOURCES)) 
OBJS:= $(patsubst %.c,%.o,$(SOURCES)) 

#Don't create dependencies when we're cleaning, for instance 
ifeq (0, $(words $(findstring $(MAKECMDGOALS), $(NODEPS)))) 
    -include $(DEPFILES) 
endif 

#This is the rule for creating the dependency files 
%.d: %.c 
    $(CC) $(INCS) $(CFLAGS) -MM -MT '$(patsubst %.c, %.o,$(patsubst %.c,%.o,$<))' $< > $@ 

#This rule does the compilation 
%.o: %.c %.d %.h 
    $(CC) $(INCS) $(CFLAGS) -o $@ -c $< 

# Now create a static library 
all: $(OBJS) 
    @$(MKDIR) bin 
    ar rcsvq $(OUT) $(OBJS) 

clean: 
    rm -rf $(OBJS) $(OUT) $(DEPFILES) 

はなぜこのメイクファイルないが適用されます$（INCS）以降の.oファイルをビルドするとき？どうすれば修正できますか？私はthirdfile.oを構築し、-Iパスを使用してgccの行のコマンドラインと型に行くとき

$ make all 
my-cross-gcc -I. -Iinc -Imy/inc/path -<compiler options> -o firstfile.o -c firstfile.c 
my-cross-gcc -I. -Iinc -Imy/inc/path -<compiler options> -o secondfile.o -c secondfile.c 
my-cross-gcc -<compiler flags> -o thirdfile.o -c thirdfile.c 
thirdfile.c:23:18: fatal error: myinc.h: No such file or directory 
compilation terminated. 

、オブジェクトファイルが正常に構築されています。出力はこれに似ています。

Answer 1

ここに仕事でヘッダファイルを扱うための2つの異なるメカニズムがあります：コンパイラをとき

foo.cからfoo.oを構築しようとしている、とfoo.cで、それは#include "foo.h"に遭遇しているが、それはfoo.hを探して行きます。 -Iフラグは、どこに見えるかを示します。それがfoo.hを見つける必要があるフラグなしで呼び出された場合、それは文句を言うでしょう。

がfoo.oをビルドしようとしているときに、どのルールを使用するかを検討して、前提条件を調べます。あなたのルールの前提条件はfoo.c foo.d foo.hなので、これらの前提条件を探します。 foo.hはどのように知っていますか？そのコマンドの1つの中のコンパイラフラグは役に立たないことに注意してください。それについての控除はありません。前提条件が見つからない場合（または作成方法がわからない場合）、その規則を拒否し、$（INCS）変数について何も知らない暗黙的な%.o規則などの別の規則を探し、あなたは上記の問題にあなたを当てます。

A）あなたが暗黙のルールを使用することができ、そしてそれは変数です：この問題は（そしてあなたは、ヘッダーの位置を見て、いくつかの実験を行うことによって確認することができます）あなたはオプションのカップルを持っている場合は

。 INCSをCFLAGSに追加するだけで、結果が得られるはずです。これはコンパイラに何をすべきかを指示しますが、依然として依存関係についてMakeが暗黙のうちに残るため、おそらく依存関係の処理が正しいことを再度確認する必要があります。

B）あなたが言うヘッダファイルを見つけるために作ることができます。

vpath %.h inc my/inc/path 

（、あなたがこれはあなたのINCS変数と冗長であることに気づくことができ、冗長性は、あなたがこの冗長性を排除することができますbad--ですが、最初に動作させることをお勧めします）。

Answer 2

firstfile.h、secondfile.hという名前のファイルがありますが、thirdfile.hという名前のファイルはありませんか？

私はあなたが与えた規則を使用できないと仮定します。そして、.hファイルを見つけたり、作成したりすることができないと思います。したがって、代わりにデフォルトの暗黙ルールを使用することにします。

Answer 3

私が想像することができるのは、「第3のファイル」の場合、あなたのデポファイルが何らかの形で時代遅れであるか破損していることです。おそらく、他のデフォルトターゲットを呼び出すことに混乱を招くほど十分に悪いです。