これは、Ubuntu Online、Fedora Online、Windows オンライン エミュレーター、MAC OS オンライン エミュレーターなど、複数の無料オンライン ワークステーションのいずれかを使用して、OnWorks 無料ホスティング プロバイダーで実行できるコマンド makepp_build_check です。
プログラム:
NAME
makepp_build_check -- makepp がファイルの再構築を決定する方法
DESCRIPTION
A: "architecture_independent", E: "完全に一致"、 I: "ignore_action", O: "only_action",
T: "target_newer"
Makepp は、特定のファイルが前回どのようにビルドされたかに関するさまざまな情報を保存します。
この情報には、ビルド コマンド、アーキテクチャ、およびすべての署名が含まれます。
ファイルの依存関係。 (すべての保存された情報はサブディレクトリにあります .makepp of
この情報のいずれかが変更された場合、makepp は通常、次のことを決定します。
ファイルを再構築します。 ビルド チェック メソッドは、makepp のリビルドの決定を制御するものです。
どの情報を確認し、どの情報を無視するかを決定します。
通常、Makepp は正しいビルド チェック メソッドを自動的に選択します。 ただし、次のことができます。
:build_check 修飾子を使用して、個々のルールの署名方法を変更します。
ルール、または build_check ステートメントを使用したメイクファイル内のすべてのルール、またはすべてのルール
-m または --build-check-method コマンド ライン オプションを使用して一度に makefile を作成します。
再構築、リポジトリ、またはビルド キャッシュのインポートを決定するために使用されるデータは、次の場所に保存されます。
内部ビルド情報ファイル。 makeppinfo、mppiで表示できます。 それぞれの下
メソッドは、そのキーを確認する方法の例を示しています。
建設 PowerSchoolで、緊急連絡先情報を定期的にチェックし、 メソッド 含まれました in ディストリビューション
現在、ディストリビューションには XNUMX つのビルド チェック方法が含まれています。
完全に一致
この方法では、ファイルの変更日が署名として使用されます。 を再構築します。
次のすべての条件に該当しない限り、ターゲット:
· 各依存関係の署名は、前回のビルドと同じです。
· 各ターゲットのシグネチャは、前回のビルド時と同じです (つまり、誰も
makepp がターゲットをビルドして以来、ターゲットをいじっています)。
· ビルド コマンドは変更されていません。
· マシン アーキテクチャ (または Perl が考えるアーキテクチャ) は変更されていません。
Makefile を再構築しない限り、"exact_match" がデフォルトの方法です (以下を参照)。
これは、正しいビルドを保証する信頼性の高い方法であり、ほとんどの場合、
あなたがしたい。 ただし、驚くべき副作用がいくつかあります。
· 従来の make でコンパイルしてから makepp に切り替える場合は、
初めて makepp を実行すると、すべてが再コンパイルされます。
· 前回のビルドで何が起こったかに関する makepp の情報を破損した場合 (例:
サブディレクトリ「.makepp」を削除するか、すべてをコピーするときにコピーしないでください
そうでない場合)、再構築がトリガーされます。
· ファイルを古いバージョンに置き換えると、再構築がトリガーされます。 これは
通常はあなたが望むものですが、驚くかもしれません。
· makepp の制御外でファイルを変更した場合 (たとえば、
コンパイル コマンドを自分で)、次に makepp はファイルを再構築します。 (もしも
これを回避したい場合は、「--dont-build」コマンド ライン オプションを確認してください。)
· 別のアーキテクチャに切り替えると、アーキテクチャに依存しないファイルが再構築されます。
建築。 多くの場合、時間がかからないため、これは通常問題ではありません。
構築する。 すべてのファイルがアーキテクチャでタグ付けされている理由
単なるバイナリ ファイルですが、多くの場合、ASCII ファイルでさえアーキテクチャです。
依存。 たとえば、Solaris の「lex」プログラムからの出力はコンパイルされません。
Linux (または、少なくとも前回試したときはそうでした)。
具体的には、ファイルは再構築されないか、リポジトリまたはビルドから取得できます
キャッシュ、次のコマンド出力が同じままである場合、つまり、の署名と一致する場合
依存関係:
mppi -k'COMMAND ARCH SORTED_DEPS DEP_SIGS ENV_{DEP,VAL}S' ファイル
アーキテクチャに依存しない
「architecture_independent」メソッドは、「exact_match」と同じですが、
アーキテクチャをチェックしません。 これは、アーキテクチャに依存しないファイルに役立ちます。
別のアーキテクチャに切り替えるときに再構築する必要はありません。 為に
たとえば、Solaris で既に "bison" を実行している場合は、おそらく再実行する必要はありません。
Linux。
"architecture_independent" メソッドは、
":build_check architecture_independent" 修飾子を生成する各ルールに追加
アーキテクチャに依存しないファイル。 デフォルトでは、Makepp はファイルが
アーキテクチャに依存しないため、 .c ファイルはアーキテクチャに依存する場合があります。 為に
たとえば、Solaris lex の出力は Linux ではコンパイルされないか、少なくとも
私が試した時は長続きしませんでした。 したがって、このビルド チェック メソッドを手動で指定する必要があります。
真にアーキテクチャに依存しないファイル。
具体的には、ファイルは再構築されないか、リポジトリまたはビルドから取得できます
キャッシュ、次のコマンド出力が同じままである場合、つまり、の署名と一致する場合
依存関係:
mppi -k'COMMAND SORTED_DEPS DEP_SIGS ENV_{DEP,VAL}S' ファイル
無視アクション
「ignore_action」メソッドは、チェックしないことを除いて「exact_match」と同じです。
アクション文字列 (コマンド)。 コマンドが変更される可能性があり、変更したくない場合があります
再構築を強制します。
たとえば、コマンドに日付を明示的に入力して、
ビルドは完了しましたが、コマンドが実行されるたびに再構築を強制したくありません
実行されました。 例えば、
BUILD_DATE := $(シェルの日付)
my_program : $(MODULES).o
$(CXX) $(inputs) -DBUILD_DATE="\"$(BUILD_DATE)\"" date_stamp.c -o $(output)
これでコンパイルされます 日付_スタンプ.c 最後のビルド日付スタンプを使用しますが、強制しません
日付が変わると再コンパイルします。 残念ながら、リンクについて何か他のことがあれば
コマンドが変更された場合 (たとえば、リンカー オプションを変更した場合)、再構築もトリガーされません。
これは、$(changed_inputs) または $? の変数
ターゲットをゼロから再構築するのではなく、単にターゲットを更新するアクション。 為に
たとえば、次のように .a ファイルを更新できます。
libmine.a : *.o : build_checkignore_action
$(AR) ru $(output) $(changed_inputs)
": build_check を指定するのを忘れた場合でも、これはほとんど機能します。
ignore_action". ただし、どの .o ファイルも変更されていないとします。コマンド
おそらく前回とは異なる「ar ru libmine.a」になります。
(例: "ar ru libmine.a buggy_module.o")、makepp はコマンドを実行します。 この中で
その場合、コマンドは時間を浪費する以外には何もしません。
古い .o ファイルが内部に残る可能性があるため、このような .a ファイルのビルドは推奨されません。
アーカイブ。 ソース ファイルを削除しても、.o ファイルは .a ファイル内に残ります。
これにより、不適切なビルドが発生する可能性があります。 次のような .a ファイルを作成することをお勧めします。
libmine.a : *.o
&rm $(出力)
$(AR) ru $(出力) $(入力)
具体的には、ファイルは再構築されないか、リポジトリまたはビルドから取得できます
キャッシュ、次のコマンド出力が同じままである場合、つまり、の署名と一致する場合
依存関係:
mppi -k'ARCH SORTED_DEPS DEP_SIGS ENV_{DEP,VAL}S' ファイル
ターゲット_新しい方
「target_newer」メソッドは、ファイルの日付のみを調べます。 依存関係が多い場合
ターゲットよりも新しい場合、ターゲットは再構築されます。 これは、
従来の Unix make ユーティリティを使用します。
「target_newer」メソッドは「exact_match」メソッドほど安全ではありません。
ビルド コマンドを変更した場合、またはファイルを
古いバージョン。 時計が正しくないと混乱することもあります
同期。 たとえば、ファイルが何らかの理由で 4 年 2048 月 XNUMX 日の日付を取得した場合、
現在から 2048 年までの間に、そのファイルに依存するすべてのファイルが再構築されます。
ファイルは変更されません。 また、別のアーキテクチャに切り替えても、
再構築します。 ルールのターゲットがビルド キャッシュから取得されないようにします。
を満たすペアの無限のセットに関連付けることができる一意の署名
よりも新しい関係。
ただし、「target_newer」メソッドを使用したい場合がいくつかあります。
· ユーザーが makepp の制御外でファイルを作成することが合理的である場合。
おそらく最も一般的な例は、makefile を生成するコマンドです。
つまり、自動構成手順です。 ユーザーは通常、configure を発行します。
手動でコマンドを実行しますが、メイクファイルには多くの場合、自分自身を更新する方法があります
自動的。 この場合、メイクファイルを強制的に再構築したくありません。
ユーザーがコマンドを手動で入力した場合は、それ自体、つまり「target_newer」メソッドは
「exact_match」メソッドよりも適切です。 実際、makepp が行おうとしている場合は、
メイクファイルをビルドすると、完了するまで「target_newer」がデフォルトのメソッドになります
メイクファイルの構築。
· makepp がファイルをビルドした後で、ユーザーがファイルを変更することが合理的である場合。 為に
たとえば、ファイルが存在しない場合は、中央の
場所、またはリポジトリからチェックアウトします。 しかし、ユーザーは許可されるべきです
それを変更します。 デフォルトの "exact_match" ビルド チェック メソッドを使用すると、makepp は
ユーザーがファイルを変更したことを検出し、新しいコピーを強制します。
中央の場所または新しいチェックアウトで、ユーザーの変更を消去します。
タイムスタンプを手動で確認する必要がある場合は、取得方法について makeppinfo の例を参照してください。
各依存関係のパス。
のみ_アクション
非常に具体的な「only_action」メソッドは、コマンドが次の場合にのみアクションを実行します
string が最後に実行されたときと異なります。 例えば、
$(ROOT)/include/%.h : %.h
&ln -fr $(入力) $(出力)
ファイルを発行しますが、ファイルが変更されたときにこれを繰り返しません。 &ln
コマンドは組み込まれているため安価ですが、makepp は分岐して監視する必要があります。
アクション全体を実行するプロセス。 公開するファイルがたくさんある場合は
はまだメリットです。 実際にはメソッドを指定しませんでした。なぜなら、ターゲットが
はシンボリック リンクであるため、このビルド チェックは自動的に使用されます。 あなただけがする必要があります
コマンドのみに依存する他のコマンドに対して指定します (通常は、
入力の名前が含まれています):
%.list : %.x : build_checkonly_action
&echo $(入力) -o $(出力)
具体的には、ファイルは再構築されないか、リポジトリまたはビルドから取得できます
キャッシュ、次のコマンド出力が同じままである場合、つまり、の署名と一致する場合
依存関係:
mppi -kCOMMAND ファイル
他のビルド チェック方法も可能です。 独自のビルド チェック メソッドを作成するには、次のようにします。
モジュール「Mpp::BuildCheck::MyMethod」を作成します。 ドキュメントを読む
Mpp/BuildCheck.pm makepp ディストリビューションで。 ほとんどの場合、ビルドチェックが必要になります
メソッドは "Mpp::BuildCheck::exact_match" から継承するため、そのドキュメントも参照してください。
ビルド チェックを変更するよりも、署名メカニズムを変更する方が一般的に有用です。
メカニズムを直接。 ビルド チェック メカニズムを変更する前に、問題があるかどうかを確認してください。
署名を変更することでより良いサービスが提供されます (詳細については、makepp_signatures を参照してください)。
カスタム ビルド チェック メソッドが役立ついくつかの理由を次に示します。
· makepp にコマンドの一部を無視させたい場合。 たとえば、コマンドがある場合
次のようなメイクファイルで:
xo : xc
ssh $(REMOTE_MACHINE) cc $< -o $@
"$(REMOTE_MACHINE)" が変更された場合、makepp が再構築を強制しないようにすることができます。 君は
「exact_match」メソッドを変更して、ssh コマンドを認識し、
マシン名。 それを達成する別の方法については、 :dispatch を確認してください。
onworks.net サービスを使用してオンラインで makepp_build_check を使用する