なぜGNUは悪くなるのですか？

GNU makeは、プロジェクトを自動的に構築するための有名なユーティリティです。 UNIXの世界では、このタスクの事実上の標準です。 しかし、Windows開発者の間ではあまり人気がなかったため、Microsoftのnmakeなどの類似物が出現しました。



ただし、その人気にもかかわらず、makeは主に欠陥のあるツールです。 その信頼性は疑わしい。 特に大規模プロジェクトの生産性が低い。 メイクファイル言語自体は難解に見えますが、同時に、元々他の多くのプログラミング言語に存在していた基本的な要素の多くが欠けています。



もちろん、ビルドを自動化するユーティリティはmakeだけではありません。 makeの制限を取り除くために、他の多くのツールが作成されています。 それらのいくつかは元のメーカーよりも間違いなく優れていますが、これはメーカーの人気に影響しませんでした。 このドキュメントの目的は、簡単に言えば、makeに関連するいくつかの問題について説明することであり、それらがあなたを驚かせないようにすることです。



この記事の引数のほとんどは、元のUNIX makeおよびGNU makeに関連しています。 今日のGNU makeは最も一般的である可能性が高いため、makeまたは「makefiles」について言及する場合、GNU makeを意味します。



また、この記事では、読者が基本レベルでmakeにすでに精通しており、「ルール」、「目標」、「依存関係」などの概念を理解していることを前提としています。

言語デザイン

メイクファイルを作成したことがある人なら誰でも、その構文の「特異性」に遭遇する可能性が高いでしょう。タブを使用します。 コマンドの開始を説明する各行は、タブ文字で始まる必要があります。 スペースは収まりません-タブだけです。 残念ながら、これはmake言語の奇妙な側面の1つにすぎません。

再帰的なメイク

ルールが別のmakeセッションを作成するときにメイクファイルルールを定義する場合、再帰makeは一般的なパターンです。 各makeセッションはトップレベルのmakefileを一度しか読み取らないため、これは複数のサブプロジェクトで構成されるプロジェクトのmakefileを記述する自然な方法です。



「再帰的なメイク」は非常に多くの問題を引き起こすため、このソリューションが悪い理由を示す記事が書かれています。 多くの困難を識別します（そのうちのいくつかを以下で説明します）が、再帰を使用しないメイクファイルの作成は実際には難しい作業です。

パーサー

プログラミング言語のほとんどのパーサーは、同じ動作パターンに従います。 最初に、ソーステキストは「トークン」または「スキャン」に分割され、コメントとスペースは捨てられ、入力テキスト（かなり自由な形式で指定）は「文字」、「識別子」、「予約語」などの「トークン」のストリームに変換されます。 次に、トークンの結果のストリームは、正しい組み合わせとトークンの順序を決定する言語文法を使用して「解析」されます。 最終的に、結果の「文法ツリー」は解釈、コンパイルなどされます。



makeパーサーはこの標準モデルに従いません。 メイクファイルを同時に実行しないと解析できません。 変数置換はどこでも発生する可能性があり、変数の値がわからないため、解析を続行できません。 その結果、言語全体の実装を作成する必要があるため、メイクファイルを解析できる別のユーティリティを作成することは非常に簡単な作業です。



また、言語にはトークンへの明確な区分はありません。 たとえば、コンマの処理方法を見てみましょう。



コンマが行の一部であり、特別なステータスを持たない場合があります。

X = y,z
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ifステートメントで比較される行をコンマで区切ることがあります。

 ifeq ($(X),$(Y))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

関数の引数をコンマで区切ることがあります。

 $(filter %.c,$(SRC_FILES))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、関数の引数間でも、コンマが行の一部にすぎない場合があります。

 $(filter %.c,ac bc c.cpp d,ec)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

（ filter



は2つのパラメーターのみを受け入れるため、最後のコンマは新しいパラメーターを追加せず、2番目の引数の文字の1つになります）



スペースは同じあいまいなルールに従います。 ギャップが考慮されることもあれば、考慮されないこともあります。 行は引用符で囲まれていません;このため、どのスペースが重要であるかは視覚的に明確ではありません。 「リスト」などのデータ型がないため（行のみが存在するため）、リスト項目の区切り文字としてスペースを使用する必要があります。 その結果、たとえばファイル名にスペースが含まれている場合など、ロジックが過度に複雑になります。



次の例は、スペースを処理するための複雑なロジックを示しています。 スペースで終わる変数を作成するには、あいまいなトリックが必要です。 （通常、行末のスペースはパーサーによってスローされますが、変数の置換後ではなく前に発生します）。

 NOTHING := SPACE := $(NOTHING) $(NOTHING) CC_TARGET_PREFIX := -o$(SPACE) #       $(CC_TARGET_PREFIX)$@
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、カンマとスペースに触れました。 makeパーサーの複雑さを理解している人はごくわずかです。

初期化されていない環境変数。

makefileで初期化されていない変数にアクセスした場合、makeはエラーを報告しません。 代わりに、同じ名前の環境変数からこの変数の値を取得します。 同じ名前の環境変数が見つからない場合、値は空の文字列であると見なされます。



これにより、2種類の問題が発生します。 まず、タイプミスはキャッチされず、エラーとは見なされません（このような状況ではmakeに警告を発行させることができますが、この動作はデフォルトで無効になっており、初期化されていない変数が意図的に使用される場合があります）。 2番目の-環境変数は、メイクファイルのコードに予期せぬ影響を与える可能性があります。 ユーザーがどの変数を設定できるかを確実に知ることはできません。したがって、信頼性のために、すべての変数を参照または+=



追加する前に初期化する必要があります。



また、「 make FOO=1



」として呼び出されたときのmakeの動作と、「 export FOO=1 ; make



」への呼び出しの間に紛らわしい違いがあります。 最初のケースでは、メイクファイルFOO = 0



は効果がありません！ 代わりに、 override FOO = 0



記述する必要がありoverride FOO = 0



。

条件式の構文

メイクファイル言語の主な欠点の1つは、条件式のサポートが限られていることです（特に、クロスプラットフォームのメイクファイルを作成するためには条件ステートメントが重要です）。 makeの新しいバージョンには、「 else if 」構文のサポートが既に含まれています。 もちろん、 ifステートメントには、ifeq、ifneq、ifdef 、 ifndefの 4つの基本オプションしかありません 。 条件がより複雑で、「and / or / not」の確認が必要な場合は、より面倒なコードを記述する必要があります。



ターゲットプラットフォームとしてLinux / x86を定義する必要があるとします。 次のハックは、「and」条件をサロゲートに置き換える通常の方法です。

 ifeq ($(TARGET_OS)-$(TARGET_CPU),linux-x86) foo = bar endif
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

条件「または」はそれほど単純ではありません。 x86またはx86_64を定義する必要があり、「 foo = bar 」の代わりに10行以上のコードがあり、それを複製したくないとします。 いくつかのオプションがあり、それぞれが悪いです：

 # ,   ifneq (,$(filter x86 x86_64,$(TARGET_CPU)) foo = bar endif # ,    ifeq ($(TARGET_CPU),x86) TARGET_CPU_IS_X86 := 1 else ifeq ($(TARGET_CPU),x86_64) TARGET_CPU_IS_X86 := 1 else TARGET_CPU_IS_X86 := 0 endif ifeq ($(TARGET_CPU_IS_X86),1) foo = bar endif
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

言語が完全な構文をサポートしていれば、メイクファイルの多くの場所を単純化できます。

2種類の変数

makeには2種類の変数の割り当てがあります。 " ：= "は、右側の式をすぐに評価します。 通常の「 = 」は、後で変数が使用されるときに式を評価します。 最初のオプションは、他のほとんどのプログラミング言語で使用され、原則として、特に式の計算が難しい場合はより効果的です。 もちろん、2番目のオプションは、主にメイクファイルで使用されます。



「 = 」（遅延計算を使用）を使用する客観的な理由があります。 ただし、多くの場合、より正確なメイクファイルアーキテクチャを使用して削除できます。 パフォーマンスの問題を考慮しなくても、遅延計算により、メイクファイルコードの読み取りと理解がより困難になります。



通常、プログラムは最初から最後まで（実行された順序と同じ順序で）読み取ることができ、いつでもその状態を正確に知ることができます。 遅延計算では、プログラムで次に何が起こるかを知らなければ、変数の値を知ることはできません。 変数は、直接変更することなく、その値を間接的に変更できます。 たとえば、「デバッグ出力」を使用してメイクファイル内のエラーを検索しようとすると、次のようになります。

 $(warning VAR=$(VAR))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

...必要なものが得られない場合があります。

パターン置換とファイル検索

一部のルールでは、％記号を使用してファイル名の主要部分（拡張子なし）を示します-一部のファイルを他のファイルから生成するためのルールを設定するため。 たとえば、 .cファイルを拡張子.oのオブジェクトファイルにコンパイルするルール「 ％.o：％.c 」。



オブジェクトファイルfoo.oを作成する必要があるが、ソースファイルfoo.cが現在のディレクトリにない場所にあるとします。 Makeには、そのようなファイルを探す場所を指示するvpathディレクティブがあります。 残念ながら、foo.cという名前のディレクトリがディレクトリで2回見つかった場合、makeは間違ったファイルを選択する可能性があります。



2つのソースファイルが同じ名前（ただし拡張子が異なる）で、横に並んでいる場合、メイクファイルの次の標準プログラミングパターンは失敗します。 問題は、「ソースファイル名=>オブジェクトファイル名」の変換で一部の情報が失われることですが、make'aの設計では逆マッピングを行うためにこれが必要です。

 O_FILES := $(patsubst %.c,%.o,$(notdir $(C_FILES))) vpath %.c $(sort $(dir $(C_FILES))) $(LIB): $(O_FILES)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その他の不足している機能

makeはデータ型を認識せず、文字列のみを認識します。 ブール型、リスト、辞書はありません。

「スコープ」の概念はありません。 すべての変数はグローバルです。

サイクルのサポートは制限されています。 $（foreach）は式を数回評価し、結果を結合しますが、 $（foreach）を使用して、たとえばルールのグループを作成することはできません。

ユーザー定義関数は存在しますが、 foreachと同じ制限があります。 変数の置換のみを処理でき、言語構文を完全に使用したり、新しい依存関係を作成したりすることはできません。

信頼性

特に大規模なプロジェクトやインクリメンタルコンパイルでは、Makeの信頼性は低くなります。 アセンブリが奇妙なエラーでクラッシュする場合があり、make cleanなどの「魔法」を使用して、すべてが修正されることを期待する必要があります。 時々（より危険な状況）すべてが見た目は良いのですが、何かが再コンパイルされておらず、アプリケーションが起動後にクラッシュします。

不足している依存関係

各ターゲットのすべての依存関係についてmakeに通知する必要があります。 そうしないと、依存ファイルが変更されたときにターゲットを再コンパイルしません。 C / C ++の場合、多くのコンパイラはmakeが理解できる形式で依存関係情報を生成できます。 ただし、他のユーティリティの場合、状況ははるかに悪くなります。 他のモジュールを含むpythonスクリプトがあるとしましょう。 スクリプトの変更は、結果の変更につながります。 これはメークファイルに対して明白かつ簡単に作成できます。 ただし、モジュールの1つを変更すると、スクリプト出力も変更される可能性があります。 これらすべての依存関係の完全な説明とそれらを最新の状態に保つことは、簡単な作業ではありません。

ラベル「最終ファイル変更時刻」の使用

makeは、ターゲットの「最終変更時刻」と依存関係の同じ時刻を比較することにより、ターゲットが再アセンブリを必要とすることを決定します。 ファイルの内容の分析は行われず、時間の比較のみが行われます。 ただし、特にネットワーク環境では、このファイルシステム情報の使用が常に信頼できるとは限りません。 システムクロックが遅れる場合があり、他のプログラムがファイルの変更に必要な時間を強制し、「実際の」値を上書きする場合があります。 この場合、makeは再構築する必要のある目標を再構築しません。 結果は、部分的な再コンパイルのみです。

コマンドラインオプション

プログラムのパラメーター文字列が変更されると、その結果も変更される可能性があります（たとえば、Cプリプロセッサーに渡される-Doptionの変更）。 この場合、makeは再コンパイルしません。これにより、誤った中間再コンパイルが行われます。



Makefileを各ターゲットに追加することで、これから身を守ることができます。 ただし、ターゲットを逃す可能性があるため、このアプローチは信頼できません。 さらに、Makefileには他のMakefileが含まれる場合があり、MakefileにはMakefileも含まれる場合があります。 それらをすべてリストし、このリストを最新の状態に保つ必要があります。 さらに、メイクファイルへの多くの変更はマイナーです。 メイクファイルのコメントを変更したという理由だけで、プロジェクト全体を再コンパイルする必要はほとんどありません。

環境変数の継承とそれらへの依存

各環境変数がmake変数になるだけでなく、これらの変数もmakeが実行されるすべてのプログラムに渡されます。 各ユーザーには独自の環境変数セットがあるため、同じアセンブリを実行している2人のユーザーは異なる結果を得ることができます。

子プロセスに渡される環境変数を変更すると、その出力が変更される場合があります。 つまり、このような状況では再構築が開始されますが、makeは開始されません。

複数の同時セッション

同じディレクトリでmakeの2つのインスタンスを同時に実行すると、同じファイルをコンパイルしようとしたときに衝突します。 おそらく、そのうちの1つ（または両方）がクラッシュします。

再構築中のファイルの編集。

makeの実行中にファイルを編集して保存した場合、結果は予測できません。 makeがこれらの変更を正しく反映するか、しない場合があり、makeを再度実行する必要があります。 または、運が悪い場合、目標の一部が再構築を必要とするような瞬間に保存が行われることがありますが、その後のmakeの実行ではこれが見つかりません。

不要なファイルを削除する

プロジェクトで最初にファイルfoo.cを使用していたが、後でこのファイルがプロジェクトおよびメイクファイルから削除されたとします。 一時オブジェクトファイルfoo.oは残ります。 これは通常許容されますが、そのようなファイルは時間の経過とともに蓄積し、時には問題を引き起こす可能性があります。 たとえば、vpath検索中に誤って選択される場合があります。 別の例：アセンブリ中にmakeによって以前に生成されたファイルの1つがバージョン管理システムに入れられたとしましょう。 このファイルを生成したルールもメイクファイルから削除されます。 ただし、バージョン管理システムは、同じ名前のバージョン化されていないファイルが既に存在することを確認した場合、通常はファイルを上書きしません（重要なものを削除する恐れがあるため）。 このようなエラーに関するメッセージに注意を払わず、このファイルを手動で削除せず、ソースディレクトリを再度更新しなかった場合、このファイルの古いバージョンを使用します。

ファイル名の正規化

異なるパスを使用して同じファイルにアクセスできます。 ハードリンクおよびシンボリックリンクを考慮しなくても、foo.c、。/ foo.c、.. / bar / foo.c、/ home / user / bar / foo.cは同じファイルを指すことができます。 makeはそれらを適切に処理する必要がありますが、彼はしません。

この問題は、ファイルシステムで大文字と小文字が区別されないWindowsではさらに悪化します。

再構築の中断または失敗の結果

プロセスの途中でアセンブリがクラッシュした場合、それ以上のインクリメンタルな再コンパイルは信頼できない場合があります。 特に、コマンドがエラーを返した場合、makeは中間出力ファイルを削除しません！ もう一度makeを実行すると、ファイルの再コンパイルが不要になったことがわかり、使用しようとします。 Makeには、そのようなファイルを強制的に削除する特別なオプションがありますが、デフォルトでは有効になっていません。

再構築中にCtrl-Cを押すと、ソースツリーが理解できない状態になる可能性があります。

増分再構築中に問題が発生するたびに、疑問があります。1つのファイルが正しく再構築されない場合、そのようなファイルがいくつあるかを知っているのは誰ですか？ このような状況では、make cleanからやり直す必要がある場合があります。 問題は、make cleanが保証を与えないことです（上記参照）。別のディレクトリでソースツリーを再度展開する必要がある場合があります。

性能

プロジェクトのサイズが大きくなると、Makeのパフォーマンスは（非線形に）うまくスケーリングしません。

インクリメンタルアセンブリパフォーマンス

プロジェクトの再構築には、再構築する必要のある目標の数に比例した時間がかかることを期待できます。 残念ながら、そうではありません。

インクリメンタルアセンブリの結果が常に自信につながるとは限らないため、ユーザーはある程度定期的に、場合によっては必要に応じて（何かがうまくいかない場合はきれいにしよう; make ）、時には絶えず（パラノイアのために ）完全に再構築する必要があります ） 一部のソースがソースと同期しなくなるリスクを負うよりも、確実にリビルドを完了するのを待つ方が適切です。

ファイルの「最終変更時刻」は、ファイルの内容を変更せずに変更できます。 これは、不必要な再コメントにつながります。

不十分な記述のmakefileには依存関係が多すぎる可能性があります。そのため、その（実際の）依存関係が変更されていなくても、目標を再コンパイルできます。 「偽の」目標の不正確な使用は、エラーの別の原因です（このような目標は常に再構築する必要があります）。

メイクファイルにエラーが含まれておらず、インクリメンタルビルドが完全に信頼できる場合でも、パフォーマンスは完全ではありません。 大きなプロジェクトで.cファイル（ヘッダーファイルではない）の1つを編集したとします。 プロジェクトのルートでmakeと入力すると、makeはすべてのmakefileを解析し、再帰的に何度も自分自身を呼び出し、すべての依存関係を調べて、再構築が必要かどうかを確認する必要があります。 コンパイラ自体の開始時間は、合計時間よりも大幅に短くなる場合があります。

再帰的なメイクとパフォーマンス

このようなシナリオでは、再帰的なmakeの不注意な使用は危険です。 プロジェクトにCライブラリに依存する2つの実行可能ファイルAおよびBのソースが含まれていると仮定すると、最上位のメイクファイルはもちろんディレクトリAおよびBに再帰的に入力する必要があります。 実行可能ファイルの1つだけをビルドする場合は、ディレクトリAおよびBでmakeを呼び出すこともできます。 したがって、同様に../Cディレクトリからmakeを再帰的に呼び出す必要があります。 そして、プロジェクトのルートからmakeを呼び出すと、2回Cに入ります！

この例では、これは恐ろしく見えませんが、大規模なプロジェクトでは、いくつかのディレクトリでmakeが何十回も見えることがあります。 そして、メイクファイルを読み取り、解析し、その依存関係をすべてチェックする必要があるたびに。 そのような状況を防ぐためのmakeの組み込みツールはありません。

パラレルメイク

makeの「並行起動」により、特に多くのコアを備えた最新のプロセッサーで、速度が大幅に向上することが期待されます。 残念ながら、現実は約束にはほど遠い。

「パラレルメイク」のテキスト出力は読みにくいです。 どの警告/行/などを確認することは困難です。 複数のプロセスが同じ環境で同時に動作する場合、どのチームを指します。

並列makeは、依存関係の正しい指定に特に敏感です。 2つのルールが依存関係を介して接続されていない場合、makeは、それらを任意の順序で呼び出すことができることを提案します。 単一のmakeが呼び出されたとき、その動作は予測可能です：AがBとCに依存する場合、最初にBが構築され、次にC、次にAになります。もちろん、makeはCからBを構築する権利がありますが、順序は定義されます。

並列モードでは、BとCを並列に構築できます（ただし、必須ではありません）。 C（実際）がBに依存しているが、この依存関係がmakefileに記述されていない場合、Cの構築は失敗する可能性が最も高い（ただし、必ずしも特定の時間に依存するわけではない）。

並列makeは、makefileで欠落している依存関係の問題を突き出します。 これ自体は良いことです。 それらは他の問題につながるので、それらをキャッチして修正できるのは素晴らしいことです。 しかし、実際には、大規模なプロジェクトでは、並列makeを使用した結果は期待はずれです。

並列makeと再帰makeの相互作用は困難です。 各make'aセッションは独立しています。つまり、各セッションは他のセッションとは独立してその作業を並列化しようとしますが、完全な依存関係ツリーの一般的な考え方はありません。 信頼性とパフォーマンスの妥協点を見つける必要があります。 一方では、単一のメイクファイルだけでなく、他のすべてのメイクファイルのアセンブリを並列化します。 ただし、makeはメイクファイル間の依存関係を認識しないため、サブメイクの完全な並列化は機能しません。

いくつかのサブメイクは並行して実行できますが、他のサブメイクはシリアルモードで実行する必要があります。 これらの依存関係を指定するのは不便であり、それらのいくつかをスキップすることは非常に簡単です。 メイクファイルツリーを解析する信頼性の高いシーケンシャルな方法に戻り、一度に1つのメイクファイルのみを並列化する誘惑がありますが、これにより、特にインクリメンタルビルドの全体的なパフォーマンスが大幅に低下します。

Microsoft Visual C ++の自動依存関係生成

GCCのような多くのコンパイラは、makeが理解できる形式で依存関係情報を提供できます。残念ながら、Microsoft Visual C ++はこれを行いません。特別なキー/ showIncludesがありますが、この情報をmake'a形式に変換するには追加のスクリプトが必要です。これには、各Cファイルで個別のスクリプトを実行する必要があります。たとえば、各ファイルのPythonインタープリターを実行することは即時の操作ではありません。

インラインルール

makeには、大量の組み込みルールが含まれています。それらは小さなメイクファイルのコードを少し単純化することを可能にしますが、通常、中規模および大規模なプロジェクトはそれらをオーバーライドします。 makeは、ファイルをコンパイルするための規則を見つけようとするこれらの追加パターンをすべて調べなければならないため、パフォーマンスに影響します。それらの多くは時代遅れです-たとえば、RSCおよびSCCSでの監査システムの使用。これらは少数の人々によってのみ使用されますが、これらのルールは他のすべてのユーザーのすべてのアセンブリを遅くします。

コマンドラインからmake -rを使用して無効にできますが、これはデフォルトの動作ではありません。 makefileに特別なディレクティブを追加することでそれらを無効にできますが、これもデフォルトではありません-多くの人がこれを忘れています。

その他

前のカテゴリに分類されないその他のメイクノートもあります。

沈黙は金

エリック・レイモンドによると、「最も古く不変のUNIXの世界の設計ルールの1つは、プログラムに興味深いことや予想外のことを言うものがない場合、それは静かであるべきだということです。行儀の良いプログラムは、必要な注意と不安を最小限に抑えて、控えめに作業を行います。沈黙は金です。」makeはこの規則に従いません。

makeを実行すると、ログには実行されるすべてのコマンドと、これらのコマンドがstdoutおよびstderrに与えるすべてが含まれます。これは多すぎる。重要な警告/エラーはこのストリームでownれ、テキストはしばしば非常に速く表示されるため読みにくくなります。make -sを

実行すると、この出力を大幅に削減できます。しかし、これはデフォルトの動作ではありません。また、コマンドラインを入力せずに、makeが現在何をしているかを表示する中間オプションはありません。

多目的ルール

一部のユーティリティは、作業の結果として複数のファイルを生成します。ただし、makeルールには1つの目的しかありません。このような追加ファイルに個別の依存関係を記述しようとすると、makeは2つのルール間の関係を検出できません。

エラーになるはずの警告

makeは警告を出力しますが、周期的な依存関係を検出しても停止しません。これは、おそらく、メイクファイルの重大なエラーを示していますが、makeはこの状況を軽度の迷惑として評価します。

同様に、makeは、1つのターゲットを作成する方法を説明する2つのルールがあることを検出した場合、警告を出力します（さらに機能し続けます）。彼は単にそれらの1つを無視します。繰り返しますが、これはmakefileの重大なバグですが、makeはそうは思いません。

ディレクトリの作成

異なる構成の出力ファイルを異なるディレクトリに配置すると非常に便利です。構成を変更するときにプロジェクト全体を再構築する必要はありません。たとえば、「debug」ディレクトリに「debug」バイナリを配置し、同様に「release」構成に配置できます。ただし、これらのディレクトリにファイルを配置する前に、ファイルを作成する必要があります。

makeが自動的に実行した場合は素晴らしいと思います-そのディレクトリがまだ存在しない場合、ターゲットを構築することは明らかに不可能ですが、makeは存在しません。各ルールでmkdir -p $（dir $ @））

を呼び出すことはあまり実用的ではありません。これは非効率的です。さらに、ディレクトリが既に存在する場合はエラーを無視する必要があります。この方法で問題を解決することができます：

 debug/%.o: %.c debug $(CC) -c $< -o $@ debug: mkdir $@
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実行可能に見えます-「debug」が存在しない場合、debug / foo.oがコンパイルされる前に作成してください。しかし、見えるだけです。ディレクトリに新しいファイルを作成すると、このディレクトリの「最終変更時刻」が変更されます。 debug / foo.oとdebug / bar.oの2つのファイルをコンパイルするとします。 debug / bar.oを作成すると、デバッグディレクトリの変更時間が変更されます。これで、debug / foo.oが作成されたときよりも新しくなります。つまり、次にmakeを呼び出すと、debug / foo.oファイルが不必要に再コンパイルされます。また、古いファイルを削除して新しいファイルを作成することで（既存のファイルを上書きするのではなく）再コンパイルを行うと、不要な再コンパイルが無限に繰り返されます。

解決策は、ディレクトリではなくファイル（たとえば、debug / dummy.txt）に依存関係を作成することです。これには、メイクファイル（touch debug / dummy.txt）で追加のアクションが必要であり、中間ファイルを自動的に削除するmakeの機能と競合する可能性があります。また、目標ごとにこの追加の依存関係（dummy.txt）を指定することに注意しないと、makeを並行して実行したときに問題が発生します。

結論

Makeは多くの欠陥がある人気のあるユーティリティです。それはあなたの人生を簡素化するか、それを複雑にすることができます。大規模なソフトウェア製品に取り組んでいる場合は、他の選択肢を検討する必要があります。makeのみを使用する必要がある場合は、その欠点に注意する必要があります。



PS：上記のすべては、この記事の翻訳です。長い間、私は同じトピックに関するトピックを書くつもりでしたが、記事を読んだ後、私は翻訳をする方が良いと思いました。著者の議論のすべてが「メイク固有」（およびこの種のユーティリティすべてに完全に当てはまるものもあります）ではありませんが、仕事でそれを使用する必要があるすべてのプログラマーは、異なるメイクアップレーキを知って理解する必要があります。