2

そのため、GNU Make の $(wildcard) 関数が Windows でディレクトリを開いたままにしておくと、この問題が発生するようです。(unsnwered) 投稿「make is hold a directory open」を参照してください。Google は、このトピックに関する多くの情報を提供していません。

つまり、Makefile はある時点で $(wildcard) 関数を使用し、ディレクトリを開いたままにします。これにより、通常、「クリーンにする」ルールが正しく機能しなくなります。「make clean」をもう一度実行すると、通常は解決します。

標準の DOS ボックスで GNU Make バージョン 3.81 を使用しています。上記にリンクされた投稿の著者は、Cygwin を使用しています。

誰かがこれに対する修正を見つけましたか?

4

2 に答える 2

2

ファイル記述子のリークのように聞こえますが、UNIX では有効期間が非常に短いプロセス (make など) には無害ですが、Windows では適切な PITA です。

これは make のバグであると言われているため、使用上の問題とは対照的に、最新のアップストリーム バージョンでソースからビルドしたときにまだ存在することを検証することによって最初に対処し、次にGNU make にバグ レポートを提出することによって対処する必要があります。プロジェクト (または適切なサポート契約を結んでいる任意のディストリビューター) を使用するか、ソースに飛び込んで自分で修正しようとします。

Linux で再現しようとしても害はありません。ここではファイル記述子のリークをチェックするのがはるかに簡単/proc/self/fdです/proc/$PPID/fd。

于 2008-10-20T23:42:36.937 に答える
0

この問題の回避策を見つけました。これにより、少なくとも安心して作業できます。

問題は、$(wildcard)関数がソース ファイルを収集するために使用されたことです。ただし、私のきれいなルールはディレクトリを削除するだけです。収集する必要はありません。したがって、基本的には、ソース ファイルを収集する必要がある Makefile の一部を条件付きステートメントに入れます。

# The clean rule is always parsed
clean:
    rm -rf $(OUTPUT_DIRECTORY)

# The compile rule is only interpreted if we did not invoke 'make clean'. We
# can test the value of $(MAKECMDGOALS) for that:
ifeq ($(filter $(MAKECMDGOALS),clean),)

SOURCE_FILES := $(wildcard ...)

compile:
    g++ $(SOURCE_FILES) ...

endif
于 2008-12-23T05:31:34.940 に答える