5

次の構造の autotools で管理されたプロジェクト ( sscce tar.gz パッケージはこちら) があります。

./main.c
./foo.c
./foo/foo.h

私configure.acは：

AC_INIT([foo], [1.0], [foo@bar.ba])
AM_INIT_AUTOMAKE([foreign -Wall -Werror])
AC_PROG_CC
AC_CONFIG_HEADERS([config.h])
AC_CONFIG_FILES([Makefile])

AC_OUTPUT

私Makefile.amは：

bin_PROGRAMS = main
main_SOURCES = main.c foo.c foo.h

それはコンパイルされ、完全に実行されました...しかし、私は自分Makefile.amが正しくなかったことに気付きました。私のメイン コードは に依存していると記載されていましfoo.hたが、実際のファイルはfoo/foo.h. 私はそれを変更し、コンパイルは以前と同じように期待どおりに機能していました:

bin_PROGRAMS = main
main_SOURCES = main.c foo.c foo/foo.h

しかし、それは不思議に思いました: 依存関係が間違っていたとき、どのように機能したのでしょうか? それは非常にうまく機能したので、依存ファイルを編集foo/foo.hして再コンパイルすることさえできました。make実際、依存関係からヘッダーファイルを削除することさえできました...

bin_PROGRAMS = main
main_SOURCES = main.c foo.c

...それでもスキャンされ、依存ファイルの再コンパイルがトリガーされます。

だから、私の質問は次のとおりです。

  • autotools によって生成されたものは、それが呼び出し中に分析される依存関係であるMakefileことをどのように認識しますか?foo/foo.hmake
  • ヘッダー ファイルをmain_SOURCES変数に追加する必要がありますか?
  • make存在しないファイルが依存関係であると宣言しているので、最初のケースで失敗するべきではありませんか?
4

1 に答える 1

6

automakeのマニュアルをご覧ください。依存関係の計算は、コンパイルの副作用として、ビルド時に行われます。依存関係の追跡の履歴も興味深いかもしれません。ここのマニュアルにはエラーがあることに注意してください。depcomp無条件に呼び出されたように聞こえますが、そうではありません（configureコンパイラがそれなしで実行できるかどうかをチェックするときのテスト：の@am__fastdepCC_TRUE@行を参照してくださいMakefile.in。

つまり、各オブジェクトの依存関係をリストするファイルは、と呼ばれる非表示のサブディレクトリに保存され.depsます。これらのファイルは最初は空であり、対応するソースファイルがコンパイルされると上書きされます。（の場合、これはおよび関連するフラグgccを介して行われます。）-MD

実行時にヘッダーをパッケージ化するmain_SOURCESように、変数にヘッダーを絶対にリストする必要があります（またはさらに良いことに）。Makefilemake distmake distcheck

make行に依存関係を実際にリストしていないため、存在しないヘッダーをリストしても失敗しませんmain_SOURCES。その割り当てを処理してから、ビルドのルール（オブジェクトファイルのみに依存します）とさまざまなオブジェクトファイル（サフィックスルールを介して）をautomake書き出します。mainヘッダーはビルドプロセスの一部への直接入力ファイルではないため、スケートをします。サンプルプロジェクトで実行make distすると、エラーが発生します。

make: *** No rule to make target `foo.h', needed by `distdir'.  Stop.
于 2012-07-22T23:17:11.573 に答える