質問の元のバージョンには、次の行が含まれていましたmakefile
:
file.o: file.c header1.h header2.h
-gcc file.c header1.h header2.h
私の答えは、問題が修正される前の元のバージョンの質問に対応しています。
a.out
コンパイラがヘッダーファイルのコンパイルに反対しない限り、コンパイル行が実行可能ファイルを生成することに注意してください。-c
コマンドラインにあるはずです。
いくつかの問題:
でmakefile
、オブジェクトファイルを再構築する必要があるのはいつですか。
回答:ソースファイルまたはヘッダーの1つに変更が含まれている場合。
子会社Q:この依存関係の線はどういう意味ですか?
file.o: file.c header1.h header2.h
子会社A:file.o
ソースファイルまたはそれに含まれるヘッダーの1つが変更された場合は、再構築する必要があります。
あなたが規定する場合:header1.h
に依存します、あなたが変更するとどうなりますheader2.h
か?header1.h
header2.h
回答:何もありません。header1.h
それ自体はコンパイルしません。変更されるのはオブジェクトファイルです。
file.c
依存header1.h
またはheader2.h
その両方を指定した場合、ヘッダーの1つを変更するとどうfile.c
なりますか?
回答:もう何もありません。あなたは変わらないfile.c
; オブジェクトファイルを再度コンパイルします。
したがって、オブジェクトファイルルールの依存関係の部分は問題ありません(自動依存関係の生成に関連する制限内)。ソースファイルがヘッダーに依存しているというルールには意味がありません。実際、ソースファイルはヘッダーに直接依存していません。(ヘッダーの内容が変更されて有効なコードが有効でなくなった場合、ソースが修正されるまで何もコンパイルされないという点で間接的に依存します。ただし、それは主題から少し外れています。)
依存関係のハードコーディングには問題があります。それらは変化します。一方、依存関係を自動的に生成するのは面倒です。支援するGCCオプション(、、、、、、、、、、など—このよう-M
な豊富なオプションはここに 問題があることを示しています!)があり、GNUには-MM
依存関係ファイルが存在する場合はそれを含める「条件付き包含」があります。彼らはしません。これらは役に立ちます。それを自動化する他の方法については、および関連するコマンドを調べてください。-MF
-MG
-MP
-MQ
-MD
-MMD
-MT
-H
make
makedepend
mkdep
自動依存関係の生成を無視すると、makefileは次のようになります。
FILES.o = file.o
file.x: ${FILES.o}
${CC} -o $@ ${CFLAGS} ${FILES.o}
file.o: file.c header1.h header2.h
make
にコンパイルするコマンドを提供しfile.c
ますfile.o
。
プログラムも使用できるようになったら、マクロother.o
に追加するだけです(そのため、複数形の名前になっています)。依存関係情報も追加できます。ライブラリも必要な場合は、リンク行にオプションを追加できます。other.o
FILES.o
LDFLAGS = -L/usr/local/lib
LDLIBS = -llocal
FILES.o = file.o other1.o other2.o
file.x: ${FILES.o}
${CC} -o $@ ${CFLAGS} ${FILES.o} ${LDFLAGS} ${LDLIBS}
file.o: file.c header1.h header2.h
ライブラリはオブジェクトファイルを追跡する必要があることに注意してください。オブジェクトファイルの前にライブラリをリストすると、他のプラットフォームでリンク時の障害が発生しやすく、ソフトウェアを構築しようとしている人を苛立たせます。