makepp_build_algorithm - クラウドでオンライン

プログラム：

NAME

makepp_build_algorithm -- makepp がメイクファイルを実行する方法

DESCRIPTION

Makepp の内部構造は、基本的な点で標準の Unix make とは異なります。 このページ
さまざまな哲学を詳細に説明します。

逆 対 フォワード 推論
Makepp は、標準の Unix make とは逆方向に動作します。 従来の Unix 製
ビルドするターゲットが与えられると、その中の文字に一致するルールが見つかります。
ターゲットのファイル名。 ターゲットがルールの依存関係のいずれよりも古い場合、
再構築されています。

たとえば、次のパターン ルールについて考えてみましょう。

%.o: %.cxx
$（CXX）$（CXXFLAGS）-c $（入力）-o $（出力）

make は、「xyz.o」というファイルを作成する必要があると認識すると、そのファイルのリストを検索します。
「xyz.o」がパターン「%.o」と一致するまでパターン ルールを適用し、その後適用します。
このルール。

Makepp は逆方向に動作します。 まず、考えられるすべてのファイルを計算します。
依存関係ファイル名の文字と一致するルールを適用してビルドします。 それからいつ
ファイルを構築する必要がありますが、それが知っているファイルの XNUMX つであるかどうかを確認するだけです。
構築方法。 既知のファイルのリストは、絶対ファイル名に基づいて保存されます。

makepp が上記のパターン ルールに遭遇すると、ディレクトリ内のすべてのファイルを検索します。
パターン "%.cxx" (つまり、"*.cxx") に一致します。 これらのファイルごとに、それが記憶されます。
対応する「.o」ファイルを生成できること。 その後、makepp がそれを発見した場合、
現在存在しない別の「.cxx」ファイルを作成できる場合、このルールも適用されます
対応する「.o」ファイルがマークされます。

これはやや非効率的に見えるかもしれませんが、ほとんどの場合、それほど遅くないことが判明しています。
そして、多くの場合、ビルドできる実質的にすべてのファイルが実際にビルドされます。
ビルドできるファイルの完全なリストを知っていると、いくつかの利点があります。

· ワイルドカードは、まだ存在しないがビルドできるファイルと一致します。

· 自動依存関係スキャナーによって検出されたヘッダー ファイルには、
存在すること。 makepp は彼らがどこにいるかを知っています。 (この問題に対する他のほとんどの解決策は、
まだ存在しないヘッダーはすべて現在のディレクトリにあると想定します。)

· リポジトリは、makepp がどのファイルをリポジトリに格納するかを事前に知っているため、実装がはるかに簡単です。
作れます。 (詳細については、makepp_repositories を参照してください。)

· どのファイルをビルドできるかを簡単に判断できます (「
「$(only_targets )」関数。

· Makepp の "$(infer_objects)" 関数は、オブジェクトが何であるかを知ることで大幅に簡素化されます。
にアクセスできるようにしています。

対 テキスト パターン
Makepp は、ビルド コマンドを、ターゲット ファイルのテキスト パターンではなく、ターゲット ファイルに関連付けます。
ファイル名。 したがって、同じファイルに異なる名前が付けられても混乱することはありません。 したがって、
たとえば、makepp は「./xyz」と「xyz」が同じファイルであることを認識しますが、他の makepp は「./xyz」と「xyz」が同じファイルであることを認識します。
ユーティリティはそうではないかもしれません。

(標準の make とは異なり) makepp は makefile をロードするため、これは特に重要です。
異なるディレクトリから。 Makefile を比較的独立させるには、
トップレベルのメイクファイルには特別な位置は与えられず、各メイクファイルはすべてのファイルを参照します
独自のディレクトリからの相対パス。 したがって、サブディレクトリからメイクファイルをロードすると、
「other_stuff」、そしてその makefile が「../xyz」を参照すると、makepp はそれが「../xyz」であることを再度認識します。
上で参照したのと同じファイルです。 (ソフトリンクされたディレクトリと混同されることもありません)
名前。）

ストアド ビルド 情報
Makepp は、ビルドする各ファイルについて、日付だけでなくさらに多くの情報を保存します。
スタンプ (標準の make が考慮するのはこれだけです)。 この情報には次のものが含まれます。

· 最後のビルド時のこのファイルの署名。これにより、ファイル自体が
変更されました。

· インクルード ファイルや推測されるその他のファイルを含む、各依存関係ファイルの名前
自動的に。 このリストが変更された場合、makepp は再構築が必要であると判断します。

· 各依存関係の署名。 このようにして、makepp は、
依存関係はターゲットよりも新しいですが、依存関係が少しでも変更されたとき。 これにより、
暗号化チェックサムなどの他の種類の署名を使用することも可能です。
ファイルの日付よりも。

· ビルド コマンド全体 (およびその cwd)。 ビルドコマンドを変更するとこのようになります
(例: コンパイラ オプションを変更する)、makepp はファイルが
自分たち自身は変わっていない。

・ 建築学、建築物、建築様式。 Linux でプログラムをコンパイルしてから、Linux に切り替えた場合
Solaris では、makepp はすべてを再コンパイルすることを自動的に認識します。

Makepp は、触れるすべてのディレクトリに「.makepp」というサブディレクトリを作成します。 の
ファイルのビルド情報 ファイル名 ディレクトリ内に保存されます .makepp/ファイル名。 場合
このサブディレクトリを削除するかファイルを変更すると、makepp は影響を受けるすべてのファイルを再構築します。

暗黙 ローディング
makepp がディレクトリ内にターゲットを構築しようとしていて、それに対するルールがまだない場合は、
または、ディレクトリ内でワイルドカードに一致するファイルを探している場合は、そのディレクトリ内を検索します。
ディレクトリにアクセスして、メイクファイルが存在するかどうかを確認します。 そうであれば、メイクファイルがロードされます
自動的に。

これは、通常、makepp に場所を明示的に指示する必要がないことを意味します。
makefiles -- 別のディレクトリ内のファイルを参照するだけで、makepp が実行します。
構築方法を自動的に判断します。

暗黙的なロードは、ディレクトリが書き込み可能な場合にのみ発生します。 したがって、あなたがしたい場合は、
makepp が決して変更されないものを大量に構築しようとするのを防ぎます。
ディレクトリは読み取り専用です。

ツリー内のツリーにいる場合、暗黙的なロードは発生しません。 RootMakeppfile(.mk) と
他のメイクファイルはそのツリーの外にあります。 一度これが欲しい場合は、
makepp の「--do-build=/」オプション。ツリーの外側のすべてをビルド可能にします。 もし、あんたが
常にこれが必要な場合は、ツリー内のどこかに「load_makefile」ステートメントを配置して、
明示的にツリーに接続します。

暗黙的なロードが邪魔になる場合 (つまり、makepp がメイクファイルをロードしすぎて無駄になる場合)
そうしないと、「
makefiles)、「--noimplicit_load」コマンドを使用してすべてのディレクトリに対してオフにすることができます
行オプションを使用するか、「no_implicit_load」を使用して選択したディレクトリに対してオフにすることもできます。
メイクファイル内のステートメント。

onworks.net サービスを使用してオンラインで makepp_build_algorithm を使用する