make は従来の UNIX ソフトウェアです。これは「実稼働エンジン」です。ファイルを作成するコマンドを呼び出すために使用されます。単純なシェル スクリプトとは異なり、make は必要な場合にのみコマンドを実行します。目標は、必ずしもすべての手順をやり直すことなく、結果 (ソフトウェアのコンパイルまたはインストール、ドキュメントの作成など) を達成することです。
機能している
このプロセスでは最終結果が以前の操作に依存するため、主にコンパイルとリンクを容易にするために機能します。
これを行うために、 make はmakefileという構成ファイルを使用します。このファイルの名前は通常Makefileです。後者は、ターゲット(多くの場合ファイルですが、常にそうとは限りません)、それらが依存する他のターゲット、およびそれらを達成するためのアクション(コマンド) を記述します。
ユーザー指定のターゲットを再構築するために、make はこのターゲットの再構築に必要なターゲットを再帰的に検索します。 (そうすることで、ターゲット上の依存関係のトポロジカルなソートが効果的に作成されます。) make の一部のバリアントは、可能であればタスクの並列実行の可能性を提供します。
依存関係ルールは、明示的 (ファイル名が明示的に指定される) または暗黙的 (ファイル パターン経由。たとえば、 file .o はfile .cに依存し、後者が存在する場合は再コンパイル経由) にすることができます。
歴史
make はもともと 1977 年にスチュアート フェルドマン博士によって開発されました。後者はその後ベル研究所で働いていました。
それ以来、いくつかの派生バージョンが開発されてきましたが、最もよく知られ使用されているのは BSD のバージョンとGNUのバージョンであり、後者は一般にLinuxシステムでデフォルトで使用されるバージョンです。これらは特定の機能が異なり、たとえば、 GNU Make用のスクリプトは BSD Make では動作しない可能性があります。
現在では、Makefile が開発者によって手動で生成されることはますます稀になってきていますが、実際のアクションが実行される環境に特に適合した複雑な Makefile の生成を容易にするautoconfなどの自動ツールから構築されています。
メイクファイルの例
Makefile の例を次に示します。
# 使用するコンパイラを指定します
CC ?= gcc
# コンパイラオプションを指定する
CFLAGS ?= -g
LDFLAGS ?= -L/usr/openwin/lib
LDLIBS ?= -lX11 -lXext
# ファイル名拡張子 *.c および *.o を接尾辞として認識します
接尾辞 ?= .c .o
.SUFFIXES: $(SUFFIXES) 。
# 実行ファイル名
プログ＝人生
# 最終的なプログラムに必要なオブジェクトファイルのリスト
OBJS = main.o window.o Board.o Life.o BoundedBoard.o
すべて: $(PROG)
# 編集およびリンク編集段階
$(PROG): $(OBJS)
$(CC) $(CFLAGS) $(LDFLAGS) $(LDLIBS) -o $(PROG) $(OBJS)
.co:
$(CC) $(CFLAGS) -c $*.c
この例では、.co が暗黙のルールです。デフォルトではターゲットはファイルですが、2 つのサフィックスが並置されている場合は、同じ名前で最初のサフィックスで終わるファイルから 2 番目のサフィックスで終わるファイルを派生するルールになります。
この目標を達成するには、アクション、コマンド$(CC) $(CFLAGS) -c $*.c を実行する必要があります。$* は接尾辞のないファイル名を表します。
一方、 all は、 $(PROG) (したがって、ファイルであるlife ) に依存するターゲットです。
$(PROG) – つまり life – は $(OBJ) (したがってmain.o window.o Board.o Life.oおよびBoundedBoard.o ) に依存するターゲットです。これを実現するには、コマンド $(CC) $(CFLAGS) $(LDFLAGS) $(LDLIBS) -o $(PROG) $(OBJS) を実行します。
構文CC ?= gcc 、またはより一般的には
制限事項
Make の制限は、Make を普及させたファイルと日付という概念の単純さから直接生じています。実際、これらの基準は有効性と信頼性の両方を保証するには不十分です。
ファイルのみに関連付けられた日付基準では、両方の欠点が組み合わされます。ファイルが書き換え不可能なメディア上に存在する場合を除き、ファイルの日付が実際に最後に変更された日付であるという保証はありません。
非特権ユーザー[ 1 ]の場合、データが指定された日付よりも後にならないことが保証されている場合でも、そのユーザーが先行した正確な日付は保証されません。
したがって、ファイルの日付がわずかに変化しただけで、それがソースであればプロダクション全体が必要であるとみなされる可能性がありますが、逆にそれがターゲットであればさらに悪いことに役に立たないとみなされることになります。
- 前者の場合、効率が低下します。
- 2 番目のケースでは、信頼性が失われます。
信頼性が高く最適な本番エンジンに日付とファイルが本質的に必要であるとしても、それだけでは十分ではなく、これを説明するにはいくつかの具体的な例で十分です。
- Make 自体は、処理するファイルのセマンティクスを完全に無視し、単にそのコンテンツを無視します。たとえば、実際のコードとコメントは区別されません。したがって、ファイル内にコメントを追加する場合、または単に変更する場合でも、C make は、それに依存するライブラリまたはターゲット プログラムを再作成する必要があるとみなします。
- 最終結果が入力データに依存する場合、それは適用される処理にも同様に依存します。これらの処理はメイクファイルに記述されています。メイクファイルの進化の場合に、以前に実行された生成を無効にすることを計画するメイクファイルの作成はまれです。実際、これを行うには、メイクファイルがそれ自体で定義されているすべての生成ルールに体系的に依存するようにすることが適切です。これが make の亜種によって直接達成されることを想像することは技術的には難しくありませんが、これは、たとえ makefile で行われた変更の影響を受けなかったとしても、すべてのターゲットに影響を与えるという副作用があります。ただし、メイクファイルを変更するプログラマは、通常、コンパイルチェーンを再度開始するかどうかを知っています。すべてを再起動する必要があると判断した場合、目的のリンクでコンパイル チェーンを再起動できるようにするために、makefile で事前に定義されたクリーニング ルール (通常はcleanと呼ばれます) が呼び出されます。
- 前の例のバリエーションとして、運用環境を制御する変数が環境変数またはコマンド ラインによって配置されるケースがあります。ここでも、make にはこれらの変数が本番環境に影響を与えるかどうか、特にこれらの変数がファイルではなくオプションを指定する場合に検出する方法がありません。
これらの理由により、新世代のプロダクション エンジンは、特定の言語の処理 (ファイル コンテンツのセマンティクス) に特化するか、すべての効果的なプロダクション特性が記録されるデータベース(プロダクションの監査) ターゲット (トレーサビリティ) にさらに結合されます。 。
代替案
いくつかの代替案があります。
- makepp: (GNU) make の派生ですが、依存関係を自動的に認識するために、含まれるコマンドとファイルの拡張可能なパーサーも提供します。変更された制御オプションおよびその他の影響が認識されます。再帰的 make の大きな問題は、正しい構築を保証するために簡単に回避できます。さらに、Perl はすべてのレベルでアクセスできます。 （リンク）
- NMake はMicrosoft のMake バージョンです。
- アリ: むしろ Java の世界にリンクしています。
- SCons: make とは完全に異なり、autoconf などのビルドツール機能の一部が含まれています。 Python を使用してツールを拡張できます。
- Speedy Make はMakefile に XML を使用し、作成が非常に簡単で、make よりも多くの自動化を提供します。
メモと参考文献
- ↑特権ユーザーにはファイルの日付を無謀にダウングレードしない十分な責任があると想定されます。