これは、Ubuntu Online、Fedora Online、Windows オンライン エミュレーター、MAC OS オンライン エミュレーターなどの複数の無料オンライン ワークステーションの XNUMX つを使用して、OnWorks 無料ホスティング プロバイダーで実行できるコマンド makepp_rules です。
プログラム：
NAME
makepp_rules -- makepp に何かをビルドするように指示する方法
DESCRIPTION
?: &,
-,
@, B: :ビルドキャッシュ、
:build_check、 D: ：急送、 E: :環境、 I: "ignore_error",
：含む、 L: ：最後のチャンス、 M: メイクパール、 N: 「ノエコ」、 P: :パーサー、
「パール」、 S: ：サイン
ルールは、makepp にファイルまたはファイルのクラスを構築する方法を指示するものです。 マケップがサポートしているのは、
make の他の実装と同じルール構文に、独自の追加がいくつか加えられています。
ルールの一般的な形式は次のとおりです。
target_expression : dependency_expression [ : オプションの引数]
行動
ターゲットのリストには自動変数を含めることはできません (「$(foreach)」を除く)。 の
依存関係リストには、ターゲットを参照する自動変数のみを含めることができます (つまり、
「$(output)」、「$(outputs)」、またはそれらの同義語)。 アクションには自動が含まれる場合があります。
変数。
makepp がルールを実行する必要があると判断した場合、ルールの各行が実行されます。
順番に実行され、いずれかがゼロ以外のステータスを返した場合、残りは実行されません（そして
コマンドラインで「-k」オプションを指定しない限り、makepp はエラーで中止されます。)
各アクションは XNUMX 行のみにする必要があります。 アクションが長すぎて、簡単に書き込むことができない場合は、
単一行の場合は、複数の行に分割し、バックスラッシュを入れて、
複数の行を XNUMX つに結合する必要があります。
アクションと次のルールを区別するには、アクションをさらにインデントする必要があります。
ターゲットと依存関係を含む行よりも。 他の実装とは異なり、
make、makepp は、インデントの量やタブ文字を使用するかどうかをあまり気にしません。
スペースではなく。 従来の Make との下位互換性を維持するためのルール
makepp は、アクションがいつ終了し、次のルールが開始されるかを決定するために使用しますが、これはやや複雑です。
· 最初のアクション行は、ターゲットを含む行よりもインデントする必要があります。
· 行が 8 つのタブ文字または XNUMX つ以上のスペースによってインデントされている場合、インデントされているとみなされます。
アクションライン。
· 空白行または右マージンに「#」文字を含むコメント行が終了します。
ただし、次の空白以外の行が 8 個以上のスペース (または XNUMX 個以上のスペース) を超えてインデントされていない限り、
タブ）。
· 行が最初のアクション行と同じかそれ以上にインデントされている場合、その行は
追加のアクションラインとみなされます。
特別なアクション項目がいくつかあります。
& この記号の後には、コマンド名と任意の数の引数が続きます。 シェル
ここでは構文は完全には理解されていません。一重引用符と二重引用符とバックスラッシュのみです。
makepp 全体と同様に、内部の文字。 コマンド名は関数につながります
「c_名前" 残りの文字列を引数として呼び出します。 そんな機能があれば
見つからない場合、これは「perl」ブロックから「run」を呼び出すのと同じです。
これにより、組み込みコマンド、makefile が提供するコマンド、または外部コマンドを効率的に呼び出すことができます。
プレフィックス「&」が選択されているのは、それが Perl の関数呼び出し元であるためです。
最初はシェルでは違法です。
$(ROOT)/include/%.h: %.h
&ln $(入力) $(出力)
ノエコ
@ 通常、各シェルコマンドは実行時に出力されます。 ただし、最初の単語の場合、
アクションのアクションが「noecho」（または文字「@」で始まる場合）の場合、コマンドは
は印刷されません。 例えば、
%.o: %.cxx
noecho $(LIBTOOL) --mode=compile $(CC) -c $(input)
これは、libtool コマンドが実行されても出力されないことを意味します。 (リブツール
通常、それ自体が実行する変更されたコマンドを出力するため、これは冗長です。
XNUMX回印刷してください。）
無視_エラー
- 通常、シェルコマンドがゼロ以外のステータスを返した場合、makepp は中止されます。
コマンドが失敗しました。 ただし、一部のプログラムは終了時にステータスを誤って設定する場合があります。
実際には致命的ではなく、全体を中止すべきではないエラーが発生する可能性があります。
編集。 を指定することで、makepp に戻りステータスを無視させることができます。
コマンドラインの最初の単語として「ignore_error」(または最初の文字として「-」)。
たとえば、
$(偽の配布):
ignore_error rm -r my_program-$(VERSION) # 以前のジャンクを削除します。
&mkdir my_program-$(VERSION)
&cp $(FILES) my_program-$(VERSION)
tar cf my_program-$(VERSION).tar my_program-$(VERSION)
このコマンドはディレクトリを作成し、そこに大量のファイルをコピーしてから、
すべてを配布用の tar ファイルに保存します。 掃除するのは良い考えです
ディレクトリの以前の内容 (以前にディレクトリに何かがあった場合)
最初の行が何をしているのか。 「rm」は失敗する可能性がありますが、その戻りステータスは無視されます。
パール
メイクパール
これは基本的に perl ステートメントと同じですが、次の場合に毎回実行されます。
メイクファイルの読み取り時ではなく、ルールの実行時です。 最初のバリアントはプレーンな Perl です
XNUMX 番目のバリアントでは、最初にステートメントを Make スタイルの変数に渡します。
拡張。
ボディにブレースを付ける XNUMX つの可能性については、次の説明を参照してください。
makepp_statements の「perl_perlcode」。 そこで説明されている XNUMX 番目のバリアントに注意してください
すべての集中線をインデントする必要があるため、ここでは意味がありません。 信号を送らなければなりません
Perl ステートメントでの「die」の呼び出しによる失敗。
ルールに従って、Perl ステートメントは現在、共通のサブプロセスで評価されます。
ウィンドウズ。 つまり、メイクファイル変数への読み取りアクセスのみが許可されます。 それも
非 Perl アクションを実行するプロセス。 したがって、exec または exit を呼び出すと混乱します。
マケップ。 しかし、これは将来的に変わる可能性があります。 Perl を呼び出す効率的な方法については、
スクリプトについては、前の項目「&」または「run」を参照してください。
$(偽のバージョン):
noecho perl {{ # $(target) & $(VERSION) from Perl:
print "これは ".f_target()" です。" $VERSION\n";
}}
echo これをシェルコマンドと組み合わせることができます
-makeperl { print "これは $(target) $(VERSION)\n" }
ルールにはいくつかの種類があり、それぞれに異なる目的があります。
明白な キャンペーンのルール
ターゲット1 ターゲット2: 依存関係1 依存関係2 ...
実行するアクション
この構文は、次のいずれかを行うために次のことを指定します。 ターゲット1 or ターゲット2、すべてのファイル
依存関係1, 依存関係2、などはすでに作成されているはずです。 すると、与えられたアクションは、
ターゲットを作成するためにシェルによって実行されます。
ファイル内の最初の明示的なルールがデフォルトのターゲットであり、指定しない場合に作成されます。
コマンドライン上の任意のターゲット。
従来の make プログラムとは異なり、makepp は通常、アクションの XNUMX 回の呼び出しを前提としています。
すべてのターゲットを作成します (依存関係がない場合を除く)。 たとえば、XNUMX つの呼び出し
of yacc は、このルールの両方の出力ファイルを作成します。
y.tab.c y.tab.h : parser.y
$(YACC) -d parser.y
make の他の実装には単一コマンドの概念がないことに注意してください。
複数の出力ファイルを生成するため、複数のターゲットを指定すると、
ターゲットごとにルールを XNUMX 回実行します。 次のような場合、Makepp はこの動作に戻ります。
これは古いスタイルの Makefile です。 具体的には、ターゲットごとにルールを XNUMX 回実行します。
次のすべてが当てはまる場合は、全体で XNUMX 回だけではなく、次のとおりです。
· ルール アクションで自動変数 $@ が言及されています。 (同義語「$(output)」または
「$(target)」はこの動作を引き起こしません。)
· ルール アクションでは、自動変数 "$(outputs)" (またはその同義語) について言及していません。
"$(ターゲット)")。
· これはパターン ルールではなく、foreach 句はありません。
たとえば、
すべてのテストインストール:
$(SUBDIRS) のサブディレクトリの場合; do cd $$subdir && $(MAKE) $@; CD ..; 終わり
は makefile の一般的なイディオムであり、makepp はそれをサポートしています。 (決して使用しないでください。
作成する新しい makefile での再帰的 make -- 「load_makefile」ステートメントを使用するか、
代わりに暗黙的に Makefile をロードします。)
同じルールをターゲットごとに XNUMX 回実行したい場合 (たとえば、ターゲットが
同様のコマンドがあります)、パターン ルール (下記を参照) または
「foreach」句。 たとえば、従来の make プログラムを使用する場合は、次のように記述します。
あいうえお：
do_something をビルドして $@ > $@
makepp では、おそらく次のように記述します。
$(foreach) : : foreach abcd
do_something をビルドして $(output) > $(output)
フォニー ターゲット
A 偽物 ターゲット ファイル システムに実際には存在しないターゲットです。 それはただの
makepp にいくつかのターゲットを構築させ、場合によっては追加のコマンドを実行させる方法。
典型的な偽のターゲットは「all」で、これは通常、可能性のあるすべてを引き起こすために使用されます。
次のように、構築されるように構築されます。
すべて: prog1 prog2 サブディレクトリ/prog3 サブディレクトリ2/libmine.a
@&echo「すべて完了しました！」
「makepp all」と入力した場合、または makefile の最初の明示的なターゲットとして all を指定した場合
（これが一般的です）「makepp」と入力するだけで、すべての依存関係が次のようになります。
ビルドされると、「すべて完了しました!」と表示されます。 この時点で、makepp はファイルを検索します。 。/全て
そしてそれが存在しないことに気づくでしょう。 大声で文句を言うでしょう。
makepp がファイルを予期しないようにするには 。/全て 終了するには、それが であることを伝える必要があります。
偽のターゲット。 メイクファイルに次のような行を追加するだけです (違いはありません)
どこ）：
.PHONY: すべて
場合によってはより便利な同等の代替手段は、「$(phony )」を使用することです。
次のような関数:
$(偽のすべて): prog1 prog2 subdir/prog3 subdir2/libmine.a
あるメイクファイル内の偽のターゲットは、別のメイクファイル内の偽のターゲットを参照できます。 これは
多くの場合、次のように「クリーン」ターゲットで行われます。
# トップレベルのメイクファイル:
# たくさんのルールやものがここにあります
＃...。
$(偽のクリーン): subdir1/clean subdir2/clean
&rm -fm my_program
次に、サブディレクトリ内の makefile は次のようになります。
# サブディレクトリ内の Makefile
＃..。
$(偽のクリーン):
&rm -fm $(ワイルドカード *.o *.a)
しかし、現在では、クリーンなターゲットの代わりに「makeppclean」コマンドを使用することになります。
ワイルドカード
依存関係リストにワイルドカードを指定しても安全です。 ワイルドカードはファイルだけではありません
存在しますが、メイクファイル内のルールに従って作成できるファイルです。 例えば、
ディレクトリ内のすべての .o ファイルからライブラリを構築するには、次のように記述できます。
libmine.a: *.o
&rm -f $(出力)
ar cr $(出力) $(入力)
これは、「.o」ファイルがまだ作成されていない場合でも機能します。
ワイルドカードは、まだ存在しないがビルドできるファイルに一致します。 これでも拾えます
ルールが後で発見されるファイル (同じメイクファイル内、またはまだ読み取られていないファイル)。 この中で
最後の点は、既知のルールに限定される「ワイルドカード」機能とは異なります。
展開されたときに結果を返さなければならないためです。
Makepp は、通常のシェル ワイルドカード (「*」、「?」、および「[]」) をすべてサポートします。 また、
ワイルドカード「**」は、間にある任意の数のディレクトリに一致します。 (このアイデアは盗まれました
zsh から。) たとえば、「**/*.c」はすべての .c ソースツリー全体のファイル。
「objects/**/*.o」はすべての .o サブディレクトリ内の任意の場所に含まれるファイル オブジェクト
またはそのサブディレクトリのいずれか、またはそのサブディレクトリのいずれか。 「**」ワイルドカードは使用できません。
任意のレベルのディレクトリへのソフト リンクをたどります。 また、偽のターゲットを返すこともありません。
Makepp のワイルドカードは、存在しても読み取れないファイルまたはディレクトリを無視します。 後
とにかく、そのようなファイルはビルドプロセスでは使用できません。 読み取り不可能なファイルを
ディレクトリは主に、指定されたファイルのディレクトリからの自動インポートを禁止するのに役立ちます。
リポジトリ。
最初の主張は、これは安全だということでした。 これは、どちらでも機能するという意味です。
ファイルはすでに存在しているか、最初にビルドする必要があります。 ただし、ある意味では安全ではありません
makepp によって構築されたファイルと引き続き一致しますが、ルールはなくなりました (例:
あなたは削除しました .c ファイルですが、 .o ファイルはまだ存在します。）これを防ぐには、
「--rm-stale」オプション。
パターン ルール
パターン ルールは、テキスト パターンに基づいて適用されるルールです。 これは、
同じルールをファイルのクラス全体に適用します。 構文は GNU make の構文と同じです
パターンルール:
%.o: %.c
$(CC) -c $(入力) -o $(出力)
これは、現在のディレクトリにある「*.c」に一致するファイルはすべて次の形式に変換できることを示しています。
指定されたコマンドを使用して、対応する .o ファイルを作成します。
いくつかのパターンの依存関係が提供される場合があることに注意してください。 たとえば、あなたの場合、 xyzo file
対応するものに依存します xyz.cpp ファイル、およびというファイル上でも moc_xyz.cflags which
コンパイラ オプションが含まれている場合、これは次のように表現できます。
%.o: %.cpp %.cflags
$(CXX) `cat $(stem).cflags` -c $(入力) -o $(出力)
複数のパターン ターゲットがある場合もあります。 例えば、
%.tab.h %.tab.c : %.y
yacc -d $(入力)
&mv y.tab.h $(stem).tab.h
&mv y.tab.c $(stem).tab.c
通常、パターン ルールは現在のディレクトリ内のファイルのみを検索します。 強制することができます
設定により、現在のディレクトリとその下のすべてのディレクトリを検索します。
makepp_percent_subdirs := 1
たとえば、メイクファイル内の最初のパターン ルールの前、またはコマンド ライン上で。
「%」とワイルドカード「*」の間には明確な違いがありますが、どちらも任意の文字列に一致します。
文字列: ワイルドカードは、その時点で完全に使用されているファイルのリストを返します。 それで
これはすべてにかかっています .o ここでビルド可能なファイル:
プログレ: *.o
$(LD) $(LDFLAGS) $(入力) -o $(出力)
これは、「*」を「%」に置き換えることでは実現できません。後者は XNUMX つずつ対応するためです。
入力と出力のマッチング。一致したステムごとに XNUMX つのルールを内部的に生成します。
静的 パターン ルール
静的パターン ルールは、限られたファイルのセットにのみ適用されるパターン ルールです。
$(SPECIAL_MODULES).o : %.o : %.cpp
$(CXX) -c $(入力) -o $(出力)
これは、パターン ルールが「$(SPECIAL_MODULES).o」内のファイルにのみ適用されることを示しています。
これは主に GNU make との互換性のためです。 foreach ルール (以下を参照) は、
同じことを行うための強力な方法。
それぞれについて ルール
上記のパターン ルール構文は、ほぼすべてのビルドをサポートするのに十分強力ですが、
場合によっては、より複雑なことを行う必要があります。 Makepp はさらに多くのことを提供します
強力な構文: ルールの「:foreach」句。
target_expression : dependency_expression : foreach ファイルリスト
行動
最も単純な種類の foreach ルールは、適用が制限されている単なるパターン ルールです。
特定のファイルのリストに。 たとえば、次のようなパターン ルールがあるとします。
makepp すべてをコンパイルする方法 .c ファイル。 ただし、次のリストがあります。 .c ファイル
何か違うことをしたい。 次のようなことができます:
# すべてに適用されるルールは次のとおりです。
％.o：％。c
$(CC) $(CFLAGS) -c $(入力) -o $(出力)
%.o : %.c : foreach $(SPECIAL_MODULES)
$(CC) $(SPECIAL_CFLAGS) -c $(入力) -o $(出力)
foreach ルールをさらに強力に使用すると、変数が
ファイルリストとターゲットに一致する各ファイルに「$(foreach)」が順番に設定され、
依存関係式が評価されます。 ファイルリストにはワイルドカードが含まれる場合があります。
まだ存在しないがビルドできるファイルにも一致します (「ワイルドカード」を参照)
makepp_rules)。
これは扱いにくい構文ですが、「$(foreach)」変数を使用できるため、非常に柔軟です。
式の中でどのような形でも現れる可能性があります。 まず、パターン ルールは実際には
foreach ルールの特殊なケース。 パターンルール
％.o：％。c
$(CC) $(CFLAGS) -c $(入力) -o $(出力)
とまったく同じです：
$(patsubst %.c, %.o, $(foreach)) : $(foreach) : foreach *.c
$(CC) $(CFLAGS) -c $(入力) -o $(出力)
(実際には内部的にはほぼそれに換算されています。)
パターンルールが適用されない場合に「:foreach」句を使用する方法の例として、
十分です。いくつか持っているとします。 .c 何らかのプリプロセッサを使用して構築されたファイル
これは入力ファイルとして .k 拡大。 それらをコンパイルしたい .c とファイル
通常とは異なるコンパイル オプションのセット .c 通常のソースファイル
ファイル。 次のようなことができます:
# 通常の .c ファイルのルール:
％.o：％。c
$(CC) $(CFLAGS) -c $(入力) -o $(出力)
# .k ファイルから .c ファイルを作成するルール:
%.c : %.k
$(プリプロセッサ) $(入力) > $(出力)
# .k ファイルから作成された .c ファイルの特別なビルド ルール:
$(foreach:%.k=%.o) : $(foreach:%.c=%.k) : foreach *.k
$(CC) $(SPECIAL_CFLAGS) -c $(入力) -o $(出力)
(これは、呼び出しではなく、もう少し簡潔な置換参照構文を使用します。
明示的に「パツブスト」。)
変数 (この例では「CFLAGS」) の値を変更したいだけであることに注意してください。
場合）ターゲット固有の変数を使用する方が便利な場合があります。
Legacy サフィックス ルール
下位互換性のために、makepp は古いスタイルの接尾辞ルールをサポートします。
.suffix1.suffix2:
行動
に相当します
%.suffix2: %.suffix1
行動
しかし、覚えるのははるかに困難です。 (どの接尾辞が最初に来ますか?) 通常、ルールが表示されます。
従来の Makefile では次のようになります。
.co：
$(CC) $(CFLAGS) -c $*.c -o $*.o
これはまったく同じです
％.o：％。c
$(CC) $(CFLAGS) -c $(入力) -o $(出力)
相反する ルール
ファイルを作成する方法が複数ある場合、makepp は簡単な手順を使用して、
どのルールを使用するかを決定します。
· ファイルを構築するための明示的なルールが矛盾しているとエラーになります。
· ワイルドカードを使用したパターン ルールと foreach ルールは、明示的なルールをオーバーライドすることはありません。 したがって
明示的なルールを使用して、パターン ルールの例外を指定できます。 (単に
「:foreach」句を使用しても、何かがパターン ルールになるわけではありません。 必要があります
「:foreach」句のファイル名の一部としてワイルドカード (「*」や「?」など) を使用します。 もしそれが
単にファイルの明示的なリストであるため、それらのそれぞれに対する明示的なルールとして扱われます。
ファイル。）
· 競合するパターン ルールが異なる Makefile からのものである場合、ルールは「より近い」ものからのものになります。
makefile は、「遠い」makefile からのルールをオーバーライドします。 「より近い」とは、メイクファイルが
ディレクトリ階層内のターゲットの近くに配置されます (つまり、
Makefile の実行元ディレクトリを基準としたターゲットは短くなります)。 これなら
Makefile を区別しないため、ロードされる Makefile からのルールが区別されません
最新のものを使用しています。
これは、ファイル内のすべてのファイルに適用するパターン ルールを指定できることを意味します。
最上位の makefile だけでディレクトリ ツリー全体をオーバーライドできます。
下位レベルのメイクファイル。 たとえば、最上位の Makefile には次のものが含まれる可能性があります。
%.o : %.c : foreach **/*.c
$(CC) $(CFLAGS) -c $(入力) -o $(出力)
サブディレクトリの XNUMX つに次のような Makefile を作成できます。
％.o：％。c
$(CC) $(SPECIAL_CFLAGS) -c $(入力) -o $(出力)
· 推論の連鎖が短いパターン ルールが他のパターンよりも優先されます。
ルール。 たとえば、次のルールがあるとします (例に基づいています)。
Linux カーネル):
%.s: %.c
$(CC) -s $(入力) -o $(出力)
%.o: %.s
$(AS) $(入力) -o $(出力)
%.o: %.c
$(CC) -c $(入力) -o $(出力)
「xyz.o」をビルドする必要がある場合は、中間の「.s」ファイルをビルドしてから、
最初の XNUMX つのルールを使用してアセンブラを介してそれを実行するか、直接
最後のルールを使用した「.o」ファイル。 ルールが少ないため、最後のルールが優先されます。
推論の連鎖におけるステップ (XNUMX つではなく XNUMX つ)。
· メイクファイル内の後のパターン ルールは、前のパターン ルールをオーバーライドします。 （これは
これは、より一般的なルールを記述する必要があることを意味します。
先に、より具体的なルールは後ほど説明します。 例えば、
%.o: %.c # 一般的なコンパイル ルール。
アクション
special_%.o:special_%.c #
異なるアクション # "special_" プレフィックス。
ルール オプション
場合によっては、makepp の実行方法を変更するために追加のオプションを指定する必要があります。
ルール。 これらのオプションは、次の行のいずれかで「:optionname value」として指定されます。
依存関係、または次の行にあります。
オプションを別の行に指定すると、同じものを使用できる場合があります。
makepp と従来の make を使用した makefile。 例えば、
ターゲット : 依存関係
: 署名 target_newer
行動
「:signature」行を解釈するため、従来の Unix make では正常に動作します。
シェルコマンドとして使用し、コロンで始まるコマンドは何も行いません。
:ビルドキャッシュ /パス/to/build/cache
ターゲット : 依存関係
: build_cache /put/cache/files/over/there
行動
このルールによって生成されるファイルに使用されるビルド キャッシュへのパスを指定します。 これ
「build_cache」ステートメントまたは「--build-cache」コマンドの効果をオーバーライドします。
このルールの line オプション (存在する場合)。 ビルドの詳細については、makepp_build_cache を参照してください。
キャッシュ。
パスの代わりに「none」を指定すると、このビルド キャッシュが無効になります。
特別なルール。 これは、保存したファイルのディスク領域の無駄を避けるのに役立ちます。
キャッシュには役に立たないことはわかっています。
再利用されない、または非常に高速に構築されるためキャッシュする価値がないためです。
:build_check build_check_method
ターゲット : 依存関係
: build_check target_newer
行動
これにより、ターゲットを再構築する必要があるかどうかを決定するためにどのアルゴリズムを使用するかを makepp に指示します。
詳細については、makepp_build_check を参照してください。 これは、
「build_check」ステートメントまたは「--build-check-method」コマンド ライン オプション (存在する場合)
このルール。
:env 変数 ...
名前付き環境変数の値への依存関係を追加します。 それらのいずれかがあれば
以前のビルドと異なる場合、ターゲットは古いとみなされます。
build_check メソッドがそう指示します。 (組み込みのビルド チェック メソッドを除くすべてのメソッド
target_newer はこれを尊重します。)
VARIABLE は「PATH_VARIABLE のファイル名」(引用符で囲んだ) 形式にすることができます。この場合、
最初のディレクトリがコロンで区切られている場合、ターゲットは古いとみなされます。
ファイル名が存在する PATH_VARIABLE の値が前回のビルドと異なります。
これを使用すると、PATH_VARIABLE が変更されたときにターゲットの再構築を回避できます。
関係ないやり方。
：急送 command ...
各シェル アクション (ただし、Perl アクションや Perl コマンドは除く) を「sh -c '...'」で囲みます。
接頭辞としてコマンドを付けますが、ターゲットはコマンドに依存しないものと想定します。
これは、アクションをジョブ キュー システムに送信したい場合に便利ですが、結果は次のようになります。
キューイングパラメータや、キューイングの有無とは無関係であると想定されます。
システムは全く使われていません。
：含む ファイルまたはパターン
ルールはコンパイラによって異なります。
％.o：％。c
: %.d を含める : 署名 C
gcc -MD -c ...
％.o：％。c
: include %.u : シグネチャ C # IBM は別のサフィックスを使用します
xlc -M -c ...
sub dependify { # Microsoft のおしゃべりを便利な形式に変える
s/\$/\$\$/g;
s/(注: ファイルを含む: *)?(.+?)\r?\n/$1 ? "'$2' " : "'".f_output()."': "/e;
}
％.o：％。c
: %.d を含める : 署名 C
cl -showincludes -c ... >$(stem).d
&sed &dependify -o +<$(stem).d
一部のコンパイラ (上記の gcc のような Intel の icc、または IBM の xlc) は依存関係を生成する可能性があります。
ファイルをその場で。 つまり、コンパイル中に、makepp が実行できる makefile を作成します。
含む。 makepp のスキャナーに対する利点は、100% のスキャンが保証されていることです。
そうです、私たちはそれに近づくしかないのです。
このオプションは、特別な方法でそれを利用します: ファイルが存在しない場合、つまり
通常、最初のビルドでは通常のスキャンが行われます。 ただし、ファイルが存在する場合は、いいえ
スキャンが発生します (これが、上記でスマート署名を指定する理由です。スキャンしないと失敗します)
タイムスタンプとサイズの愚かなデフォルトに戻ります)。 代わりに、その前にファイルが含まれます。
ルールを実行しています。 ルールが正常に実行されると、ルールはすべて忘れられます。
ファイルが古い可能性があるため、初めて読み取ります。 代わりにこう書かれています
最新のビルド情報を得るために、ファイルが変更された場合は再度ファイルを更新します。
警告: これは本質的に信頼性がありません。 依存関係ファイルは、まさに
依存関係にあるルール。 一方、コンパイラはすべてのことを知っています。
これは内部サブインクルードであり、makepp は通常これを無視します。 これは信頼性です
コンパイラ パッチがサブインクルードのみを修正する場合にのみ利点があります。 の
その代償として、makepp はさらに多くのファイルを参照することになり、時間がかかります。
「#include」ステートメントを削除すると問題が発生します & 対応するファイル:
前回のときから依存関係ファイルに引き続き記述されます。
必要です。 このような場合は、依存関係ファイルを編集して依存関係を削除する必要があります。
それはもはや実現不可能です。
ビルド キャッシュからファイルをフェッチするため、この機能はビルド キャッシュでは使用できません。
ファイルについてすべてを知っている必要があります。 ただし、依存関係ファイルはそれらに依存します
makepp はファイルを読んで学習します。 このような循環依存関係は通常は発生しません。
信頼性の高いビルド システムで可能です。 リビルド後は例外です。
そして依存関係ファイルを再度読むと、すべてが再び正しくなります。
リポジトリ内でビルドする場合、makepp は依存関係ファイルを
1 つ目のリポジトリ。 これは他のファイルとは異なり、最初のファイルが取得されます。
予想通りの署名付き。 これは、ビルド キャッシュが不足している場合よりも優れています。
署名があっても、ファイルが見つかりません。
：最後のチャンス
次のような制限のないルールを有効にします。
%.foo foo%.bar: :last_chance
&echo $@ -o $@
&cp $(出力)
このようなルールでは、実質的に無限の数のターゲットが生成される可能性があるため、
このルールのターゲットは、次の場合を除き、$(ワイルドカード) 関数またはパターン ルールと一致しません。
他の何かが、ターゲットを具体的に参照することによって、ルールをすでにインスタンス化しています。
さらに、「--rm-stale」を指定すると、以前のターゲットから残ったターゲットが
makepp run をビルドする唯一の方法が last_chance ルール経由である場合、makepp の実行は古くなっているように見えます。
これはターゲットに対してまだインスタンス化されていません。これは望ましい動作です。
ワイルドカードに誤って依存すると、ビルドはより一貫して失敗します。
前回の実行のターゲットと一致します。
「:last_chance」オプションは、
ワイルドカードの一致に関するルール。
:パーサー パーサー
これにより、ファイルを検出 (インクルード) するためのコマンドを解析する方法が makepp に指示されます。 いつもの、
makepp は、コマンド自体の単語に基づいてこれを行う方法を推測します (「
詳細については、makepp_scanning を参照してください)。 ただし、makepp の推測が間違っている場合は、次のようにすることもできます。
次のように、パーサーを明示的に指定します。
%.o: %.abc
: パーサー c_compilation
ここでのアクション
これにより、makepp は C/C++ の場合と同じ解析とスキャンを実行します。
build コマンド (アクションが C コンパイルとして認識されない場合でも)。
デフォルトのパーサーはコマンドによって異なります。 「:parser」オプションを指定しない場合は、
次に、各コマンドの最初のワードが検査されます。 たとえばコンパイルまたはリンクの場合
コマンドを実行すると、makepp は「c_compilation」パーサーを使用します。 またはコマンドが次のような場合
GNU のバリアント、「gcc_compilation」。 パーサーが見つからない場合は、「なし」パーサーが使用されます。 のために
これについての詳細、または独自のパーサーを作成するか、makepp のパーサーを変更したい場合
デフォルトのパーサーについては、makepp_scanning を参照してください。
これはルール内のすべてのコマンドに適用されるため、希望どおりではない可能性があることに注意してください。
%.o: %.c : パーサーの C コンパイル
@echo '$(出力)を構築'
@funny_cc ...
これはまた、「echo」をコンパイラとして解釈し、その引数「Building」を推測します。
mymodule.o' を暗黙的な依存関係として使用します。 これは、次のような苦情につながります。
そのようなファイルを構築する方法がわかりません。 この場合、次の方が良いでしょう
「register_parser」。 そこにはその方法の説明があります パーサー として与えることができます
クラス名または関数名として。
：サイン 署名方法
ターゲット : 依存関係
: 署名MD5
行動
これにより、依存関係が変更されたかどうかを判断するためにどのアルゴリズムを使用するかを makepp に指示します。
詳細については、「makepp_signatures」を参照してください。 に含まれる署名メソッド
makepp ディストリビューションは、「plain」、「md5」、「C」、または「c_compilation_md5」です。
「共有オブジェクト」。 これは、「-m」または「-m」で指定された署名メソッドをオーバーライドします。
「--signature-method」コマンドラインオプション、または「signature」ステートメントを使用します。
スペシャル 文字
Makepp は、コロンやスペースなどの特殊文字を含むファイル名をサポートできます。
たとえば、ファイル「b:thing」から「a:thing」というファイルを作成するとします。
このようにルールを記述することはできません。
a:thing : b:thing # これは構文エラーです
&cat $(入力) -o $(出力)
なぜなら、makepp はどのコロンがターゲットと依存関係を区切っているのか、そしてどれが依存関係であるのかを知らないからです。
ファイル名の一部。 代わりに、次のように名前を引用符で囲みます。
「a:物」 : 「b:物」
&cat $(入力) -o $(出力)
これでルールは明確になりました。
Makepp の引用構文はシェルの構文とよく似ています。 たとえば、単一の
二重引用符の代わりに引用符を使用することも、特殊文字をバックスラッシュでエスケープすることもできます。
a\:物 : 'b:物'
&cat $(入力) -o $(出力)
たとえば、ファイル名が "'"!;\$" であるとします。なぜそのようなファイル名が必要なのかを説明します。
わかりませんが、makepp (およびシェル) に指定できる方法がいくつかあります。
「」「!;\$$」
"'\"!;\\$$"
makepp がいつ引用符を削除するか、いつシェルが引用符を削除するかに注意してください。 マケップが見ている
次の場合にのみ引用符を付けます。
· 「ifeq」ファミリーのテスト内
· ルールコロンの前後
· makepp 組み込みコマンド内
· ファイルに関連する関数内
シェルとは異なり、makepp は変数に引用符を代入するときに引用符を展開しません。 したがって
次のルールは同じです。
FILE = 'スペースを含む名前'
x := $(print $(FILE)) # 引用符がまだ存在することを確認するためだけに
$(FILE): # makepp によって削除された単一ファイルの周囲の引用符
&echo hello -o$(FILE) # makepp によって単一ファイルの周囲の引用符が削除される
そこにエコー >>$(FILE) # 単一ファイルの周囲の引用符がシェルによって削除される
「スペースを含む名前」:
&echo hello -o'スペースを含む名前'
そこにエコー >>'$(output)' # 上記で引用符が削除されているため、再度追加します
(シェルとは異なり) "$" で始まる変数は単一の内部でも展開されることに注意してください。
引用。 ドル記号は引用符やバックスラッシュで保護できません。 リテラルを取得するには
ドル記号。二重ドル記号を使用します。例:
$(すべて偽):
@&echo これはドル記号です: $$
@for val in abcd; $$val をエコーします。 終わり
一般に、ほぼすべての特殊文字を引用符で囲むことで処理できるはずです。
何らかの方法で。 これには、スペース、制御文字などが含まれます。ただし、次の点に注意してください。
現在、makepp のコメントの削除はやや単純化されており、「#」文字はすべて削除されます。
先頭に空白がある場合は、引用方法に関係なくコメントとして解釈されます。
ターゲットまたは依存関係の名前が「$(output)」のような自動変数に入れられると、
引用符とバックスラッシュは削除されます。 つまり、参照したい場合は、
アクション内のファイル名は、おそらく次のように再度引用符で囲む必要があります。
「スペースを含むファイル名」:
echo "特別なコンテンツ" > "$@"
$@ を引用符で囲まないと、シェルは次のコマンドを認識します。
echo "特別なコンテンツ" > スペースを含むファイル名
これは、「スペースを含むスペシャルコンテンツファイル名」という文字列をファイルに書き込みます。 a.
おそらくこれはあなたが望んでいることではありません。
onworks.net サービスを使用してオンラインで makepp_rules を使用する
