これは、Ubuntu Online、Fedora Online、Windows オンライン エミュレーター、MAC OS オンライン エミュレーターなどの複数の無料オンライン ワークステーションの XNUMX つを使用して、OnWorks 無料ホスティング プロバイダーで実行できるコマンド makepp_repositories です。
プログラム：
NAME
makepp_repositories -- バリアント ビルドのリポジトリを使用して、
中央のソースセットなど
DESCRIPTION
A 倉庫 デフォルトのディレクトリの外側にあるディレクトリまたはディレクトリ階層です。
Makefile が現在のディレクトリ ツリーに必要とするファイルが含まれています。 マケップ缶
ファイルがリポジトリから現在のディレクトリ ツリーにある場合、ファイルを自動的にリンクします。
必要です。 リポジトリは、「VPATH」変数と同様の機能を提供しますが、（
他のバージョンの make では「VPATH」)、makefile に特別なことを行う必要はありません。
彼らを働かせるために。
リポジトリは、「-R」または「--repository」コマンド ライン オプション、または
makefile 内の「repository」ステートメント。 makepp を呼び出す習慣がある場合は注意してください。
ビルド ツリーのさまざまなサブディレクトリにあると、誤って再インポートしてしまう可能性があります。
別の場所のリポジトリ。 これに対する安全策として、使用する場合は、 RootMakepp ファイル、マケップ
インポートされる場所の上または下にあるものが見つかった場合、開始を拒否します。
これは、オペレーティング システムのユニオン ファイルシステム (unionfs...) にある程度似ています。
現在のディレクトリは、最上位の書き込み可能なレイヤーのようなものです。 すべてのリポジトリは次のようになります
下位の読み取り専用レイヤー。
リポジトリは、次のようなさまざまな状況で役立ちます。
· オブジェクトと実行可能ファイルを別のディレクトリに置きたいが、
Makefile は、それらをソースと同じディレクトリに配置するように作成されます。
· 同じプログラムを XNUMX つの異なる方法でビルドしたい場合 (例: XNUMX つの異なる方法でビルドする)
コンパイル オプションのセット、または XNUMX つの異なるアーキテクチャ用)。
· ソース ツリーの全体または一部への書き込みアクセス権がない場合。
· 複数の開発者が同じプロジェクトに取り組んでおり、共通のソースがある場合
プロジェクトのすべてのソースが含まれるリポジトリ。 各開発者が変更できるのは、
他のファイルに影響を与えることなく、ローカル ディレクトリ内のファイルを変更する必要がある
開発者と makepp はソースから未変更のファイルを自動的にフェッチします。
リポジトリ。
Makepp のリポジトリの実装では、ビルド コマンドを書き直す必要はありません。
(たとえば) cons のリポジトリとはまったく異なります。 Makepp はシンボリック リンクを
コマンドがそれを期待しているディレクトリ。 コマンドが以下を参照しない限り、
絶対ディレクトリの場合、まったく同じシェル コマンドがリポジトリのファイルに対して機能します。
これは、コンパイル コマンドだけでなく、あらゆる種類のコマンドに対して機能することを意味します。
あなたのメイクファイルに入れることを考えることができます。
Makepp には、と呼ばれる別の種類のメカニズムがあります。 ビルド キャッシュ 同じことのいくつかを解決します
さまざまな問題を別の方法でリポジトリとして扱うことができます。 問題に応じて、ビルド
キャッシュはリポジトリよりも役立つ場合があります。 詳細については、「makepp_build_cache」を参照してください。
ビルド キャッシュ、およびビルド キャッシュとリポジトリの比較。
例
リポジトリについては、何ができるかをいくつかの例で説明するのが最も適切です。
異なる 編集 オプション
次のような Makefile を含む単純なプログラムがあるとします。
CFLAGS = -O2
OBJECTS = アオボコ
my_program: $(OBJECTS)
cc $(入力) -o $(出力)
%.o: %.c
cc $(CFLAGS) -c $(入力) -o $(出力)
この Makefile は、ファイル「ao」、「bo」、「co」、および「my_program」を同じディレクトリに配置します。
ソースファイルとして。
バイナリ ファイルを別のディレクトリに置きたい場合があります。 たとえば、あなたは
いくつかの異なるアーキテクチャでプログラムを構築する可能性があり、バイナリは必要ありません
一方のアーキテクチャ上のファイルは、もう一方のアーキテクチャ上のバイナリ ファイルに置き換えられます。 あるいは、あなたはそうかもしれません
以前のコンパイルを消去せずに、一時的な変更を加えて再コンパイルしたい
結果。 リポジトリがない場合は、メイクファイルを変更して
他の場所にあるオブジェクト。
ただし、リポジトリを使用すると、メイクファイルをまったくいじる必要がありません。 考えます
次の一連のコマンド:
% cd my_program_source
% makepp # 上記の makefile を使用してビルドし、
# オブジェクト ファイルがディレクトリに移動します
# 私のプログラムソース。
％ CD ..
% mkdir binary-debug # をビルドするためのクリーンなディレクトリを作成します。
% cd binary-debug # オプションが異なる同じプログラム。
% makepp -R ../my_program_source CFLAGS=-g
# これでオブジェクトはバイナリデバッグに入ります。
最初の makepp コマンドは、最適化を使用してソース ファイルをコンパイルし、オブジェクトを配置します。
ディレクトリ「my_program_source」にコピーします。それがメイクファイルの想定であるためです。
する。 ここでプログラムを再構築したいのですが、「CFLAGS」の値を次のように変更したいと考えています。
デバッグ用にコンパイルします。 コマンドラインで「CFLAGS」の新しい値を指定し、
「-R」オプションを使用して、makepp に「my_program_source」ディレクトリがリポジトリであることを伝えます。
makepp が現在のファイルにまだ存在していないファイルが必要であることに気づくたびに、
ディレクトリにある場合は、リポジトリ内を調べます。 この場合、最初にメイクファイルを探します。
これは「binary-debug」サブディレクトリには存在しません。 したがって、へのシンボリックリンクを作成します
「my_program_source」の makefile からそれを取得し、makefile を読み取ります。 それから
「ao」をビルドするにはファイル「ac」が必要であることに気づき、「ac」にリンクします。
リポジトリから。 「ac」に「my_program_source」に含まれるファイルが含まれる場合、
これらも自動的にリンクされます。 注: これらのリンクは何かに役立ちます
デバッグに似ていますが、気に入らない場合は、「makeppclean -R」で削除できます。
「binary-debug」でビルド コマンドを実行しても、次のファイルには影響しません。
「my_program_source」。 したがって、同じソース ファイルのセットから、XNUMX つの異なるソース ファイルが作成されます。
プログラムのコピー。XNUMX つは最適化してコンパイルされ、もう XNUMX つはデバッグ用にコンパイルされます。 そして
これはメイクファイルにまったく触れずに起こりました。
単に再コンパイルして上書きするのではなく、リポジトリを使用する利点
元のバイナリは、バグを修正して最適化されたバイナリに戻したい場合に使用されます。
バージョンに応じて、すべてを再コンパイルする必要はありません。 元のオブジェクトファイルはまだ残っているので、
それらのほとんどがまだ有効であるため、再コンパイルにかかる時間を大幅に節約できます。
関係するソース ファイルが XNUMX つだけの場合、これは大きな違いはありませんが、
完了までに数分から数時間かかる大規模なビルドにより、プログラマの時間と時間を節約できます。
フラストレーションは重大な場合があります。
再建 XNUMXつ file a マイナー 変形 〜へ 編集 コマンド
Makepp はリポジトリからソース ファイルのみをフェッチしません。 オブジェクト ファイルが
リポジトリを再構築する必要はなく、リポジトリが使用されます。 たとえば、わずかな
上記の Makefile を変更します。
CFLAGS := -O2
A_CFLAGS := -O6 -funroll-loops
オブジェクト := アオボコ
my_program: $(OBJECTS)
cc $(入力) -o $(出力)
%.o: %.c
cc $(CFLAGS) -c $(入力) -o $(出力)
アオ：AC
cc $(A_CFLAGS) -c $(入力) -o $(出力)
「ao」にはタイムクリティカルなコードが含まれているため、より高いレベルでコンパイルされるという考えです。
他のオブジェクトよりも最適化されます。 さて、どれだけ違うかをテストしたいとします。
タイミングはコンパイル オプションによって異なります。 リポジトリはこれにも役立ちます。
% cd my_program_source
% makepp # 上記の makefile を使用してビルドし、
# オブジェクト ファイルがディレクトリに移動します
# 私のプログラムソース。
％ CD ..
% mkdir no-unrolling # を構築するためのクリーンなディレクトリを作成します。
% cd no-unrolling # オプションが異なる同じプログラム。
% makepp -R ../my_program_source A_CFLAGS=-O2
％ CD ..
% time no-unrolling/my_program # プログラムの XNUMX つのバージョンをベンチマークします。
% 時間 my_program_source/my_program
Makepp は以前と同様に続行し、makefile のコピーにリンクしてからオブジェクトを検査します。
ファイル。 「bo」と「co」のオプションがあるため、「ao」モジュールのみを再コンパイルする必要があります。
変わっていない。 Makepp は、リポジトリの「bo」と「co」を使用できることに気づきました。
ただし、「no-unrolling」ディレクトリ内の「ao」を再コンパイルします。
コンパイルが完了すると、プログラムの XNUMX つの異なるバージョンを作成できます。
ベンチマークされた。
再建 a マイナー 変形 〜へ source
ここで、「ac」に変更を加え、その前後でプログラムのベンチマークを行うとします。
変化。 リポジトリが再び役に立ちます。 次の一連のコマンドを考えてみましょう。
% mkdir 変更-a
% cp my_program_source/ac 修正済み-a
% cd 変更-a
% emacs ac # このモジュールのみにいくつかの変更を加えます。
% makepp -R ../my_program_source
ここでは、必要な XNUMX つのソース ファイルだけを含む新しいディレクトリを作成しました。
修正する。 Makepp は「modified-a」サブディレクトリから「ac」を取得しますが、次のコピーを使用します。
「my_program_source」ディレクトリの「b」と「c」。 バイナリを一切変更せずに
「my_program_source」内のファイルに合わせて、プログラムの別のコピーを作成しました。
「ac」への変更が組み込まれています。 他の開発者がそのソースを使用している場合
"my_program_source" は、変更の影響を受けません。
したがって、リポジトリは、プログラムのバリアントを構築するための迅速な方法として使用できます。
メイクファイルに複雑な条件を追加します。 オリジナルにはどのファイルもありません
ディレクトリが変更されます。 必要に応じて使用されます。
使い方 a ディレクトリにジョブを開始します。 階層
リポジトリは実際には単なる単一のディレクトリではなく、ディレクトリ階層全体です。
あなたが使用すると仮定します /私たちの/図書館 リポジトリとして。 今 /私たちの/図書館 多く含まれる可能性があります
サブディレクトリ、例: /私たちの/ライブラリ/gui /私たちの/図書館/ネットワーク。 次のコマンドを考えてみましょう。
% makepp -R /our/library
ディレクトリ内のファイルを参照するメイクファイル内のコマンド 。/通信網 実際に
～からファイルを取得する /私たちの/図書館/ネットワーク、および同様に ./グイ。 自動的にマケップ
リポジトリには存在するが、現在のディレクトリには存在しないディレクトリを作成します。
連結 〜へ どれか 場所 in file
上記の例はすべて、リポジトリから現在のファイルにリンクされているファイルを示しています。
ディレクトリまたはそのサブディレクトリですが、実際には makepp を使用してそれらを任意の場所にリンクさせることができます
書き込みアクセス権のあるファイル システム内。 これは指定することで行われます
「-R 新しい場所=古い場所」。
たとえば、次のように入力するのは少し面倒な場合があります。
mkdir 代替ビルド
cd 代替ビルド
マケップ -R ..
次のように、XNUMX つのコマンドですべてを行うことができます。
makepp -R 代替ビルド=。 -F 代替ビルド
「-F」または「-makeppfile」は、メイクファイルをロードする前にそのディレクトリに変更されます。 絶対です
「-F」の前に「-R」を指定してください。 この例では、新しいビルド ツリーが
リポジトリ。 を使用するとそれは機能しません RootMakepp ファイル なぜならマケップは安全策を講じているからです
入れ子の木に対して。 を使用する場合も良い考えではありません **なぜなら、もしあなたが構築するなら
リポジトリでは、このサブツリーで編集および生成されたファイルも検索されます。
ファイル システム内の別の場所を割り当てることは、より複雑な場合にも役立つ場合があります。
builds には、いくつかのライブラリのサブディレクトリがあります。 たとえば、次のコマンドがあります
以前、私のプログラムの XNUMX つのバリアントをビルドしていました。
% makepp -R テストビルド/seescape=/src/seescape \
-R テストビルド/HLib=/src/HLib \
-R テストビルド/H5pp=/src/H5pp \
-R qwt=/src/external_libraries/qwt \
-F テストビルド/シースケープ
このコマンドは、XNUMX つの異なるリポジトリからファイルをロードし、次に、
./テストビルド/seescape ディレクトリを作成し、そこでメイクファイルを実行します。 に含まれるファイル
で始まるディレクトリツリー /src/seescape にリンクされています ./テストビルド/seescape。 に
つまり、makepp はファイルを一時的にリンクします。 /src/seescape/gui/image_canvas.cxx 〜へ
./test-build/seescape/gui/image_canvas.cxx 必要なときに。 このコマンドは次の場合でも機能します
「test-build」ディレクトリがまだ存在しない場合。 makepp があなたのためにそれを作成します。 (でもあなたは
コマンドラインでは「-F」オプションの前に「-R」オプションを指定する必要があります。)
複数 同等の リポジトリ
あなたのプロジェクトがいくつかのかなり自律的なグループによって維持されているとします。 XNUMXつ持っていてもいいでしょう
本番環境または少なくともすべてのソースを含む完全なリポジトリ
テストに成功しました。 すべてのグループは、（の一部）を含むほとんど空のリポジトリを持つことができます。
同じ構造で、グループのメンバーが開発を完了したファイルが含まれています。
開発者の現在のディレクトリには、開発中のファイルが保存されます。 グループ
リポジトリが最初に指定され、本番リポジトリが最後になります。
グループ リポジトリに見つからないファイルが提供されます。
$ makepp -R/グループ/リポジトリへのパス -R/本番/リポジトリへのパス
これはおそらくそのディレクトリに対してかなり静的であるため、ファイルを配置することをお勧めします。
.makepprc ルートには次の内容が含まれます。
-R/グループ/リポジトリへのパス -R/本番/リポジトリへのパス
または、固定パスがあると仮定して、メイクファイルに次のように記述することもできます。
リポジトリ /path/to/production/repository
また、オプションはメイクファイルが読み取られる前に表示されるため、その後、単に呼び出すことができます。
$ makepp -R/パス/to/グループ/リポジトリ
リポジトリ as 固定の 部 of ビルド
常に何らかのリポジトリを使用することがわかっている場合は、「リポジトリ」または「vpath」を使用できます。
メイクファイル内のステートメント。
注意事項 リポジトリ
日時 リンク 取得する in 方法
ファイル階層を迂回する方法を見つけたり、デバッガーがファイルを見つけられるようにしたりするために使用されます。
ソースを構築するときにリンクを使用すると便利です。 しかし、編集したいときは、
ファイルを作成したり、バージョン管理と再同期したりすると、リンクが邪魔になる可能性があります。 あれは
これは、システムがリンクをたどってリポジトリ内のファイルに書き込むためです。 ない限り
それは物事を区別するためだけに使用される個人的なリポジトリです。それはあなたが望むものではないかもしれません
欲しいです。
パブリック ファイルの不注意による上書きに対する保護策として、
リポジトリ内のソースは書き込み不可です。 書き込みを削除するだけでは不十分な場合もあります
バージョン管理システムが編集のためにファイルをロックすることを要求するためです。
これを実行することもできますが、再同期中にファイルを一時的に書き込み可能にします。 そうだとしたら
この場合、リポジトリは実際には別のユーザーに属している必要があります。
これを克服するには、いくつかの戦術があります。
· 編集するソースは、ビルド ツリーとは別のリポジトリに保存します。 いつでも
以前に別のリポジトリからフェッチしたファイルをこのリポジトリに配置すると、
リポジトリを編集すると、makepp はそれに気づき、そこからリポジトリを取得します。
最初に指定するリポジトリ。
· 書き込み用のコピーを作成する前に、必ずファイルを削除してください。 フォローすると、
上記の安全策の提案、これを忘れると、次の場合にエラー メッセージが表示されます。
書き込み。 これを助けるために、次の関数「delink」は XNUMX つのリンクをコピーで置き換えます。
リンクされたファイルの。 最初のバリアントはすべての種類の Bournish シェル用で、XNUMX 番目のバリアントは
XNUMX つは csh (または少なくとも tcsh) 用です。
$ delink() { { rm $1 && cat >$1; } <$1; }
% エイリアス delink '( rm \!:1 && cat >\!:1; ) <\!:1'
· 必要がないと思われる場合は、いつでもすべて削除できます。
makepp を実行するたびに、バックグラウンドで実行される可能性があります (短い形式または長い形式):
makeppclean --recurse --only-repository-links
mppc -rR
しないでください ビルド in a 倉庫 間に つかいます
リポジトリは、リポジトリとして使用されている間は読み取り専用になります。 マケップは
ビルド中にリポジトリ内のファイルを変更しても、正しく動作します。
その時点で他の人がリポジトリを使用していない場合は、夜間ビルドでも問題ないかもしれません。 前に
ビルドが開始され、makepp はリポジトリに存在するすべてのファイルのリストを取得します。
表示されると予想されるファイルを除き、リストを更新することはありません。
構築中に変更されるリポジトリが必要な場合は、makepp のリポジトリを検討するとよいでしょう。
ビルド キャッシュ メカニズム (makepp_build_cache を参照)。 あるいは、「貧しい人の言葉」を使用することもできます。
リポジトリ": 明示的なルールをメイクファイルに組み込んで、次のようなソフト リンクを作成できます。
この：
%.c : $(directory_I_wish_was_a_repository)/%.c
&ln -fs $(入力) $(出力)
これはソース ファイルに対してのみ機能します。 ファイルをリンクするためにこれを簡単に使用することはできません。
すでにリポジトリに構築されていますが、まだ構築されていない場合はここで構築します。
ファイルを構築する XNUMX つの方法としてのみ使用できます。
の 相対 ファイル名
リポジトリは完全に透過的に動作します if メイクファイル つかいます の 相対 ファイル名.
上記の例では、makefile が /src/seescape を指します ../HLibしかし、
上記のコマンドは、それが参照されている場合、期待どおりに機能しません。 /src/HLib。 使用する必要がある場合
絶対ファイル名を使用する場合は、それらを make 変数に入れて、上書きすることができます。
コマンドラインは次のようになります。
% makepp -R テストビルド/seescape=/src/seescape SEESCAPE=/home/holt/テストビルド/seescape \
-R テストビルド/HLib=/src/HLib HLIB=/home/holt/テストビルド/HLib \
-R テストビルド/H5pp=/src/H5pp H5pp=/home/holt/テストビルド/H5pp \
-R qwt=/src/external_libraries/qwt QWT=/home/holt/test-build/qwt \
-F テストビルド/シースケープ
上記は、「HLib」ディレクトリがすべてのファイルで「$(HLIB)」として参照されている限り機能します。
メイクファイル。 ディレクトリには絶対パスを指定する必要があることに注意してください。
makepp cd を実行して、makefile を読み取る前に「test-build/seescape」を実行します。 これは長引くことにつながります
複雑な make コマンド。 可能な場合は相対パスを使用してください。
マケップ しなければなりません 知っています 自己紹介 を 依存関係
makepp が知らない隠れた依存関係がある場合、リポジトリは機能しません。
について。 (実際、リポジトリを使用してビルドを実行することは、忘れられたものをチェックする XNUMX つの方法です)
依存関係。 ただし、このチェックのためだけに、ビルド キャッシュと組み合わせないでください。
構築するのではなく、そこから何かを取得すると、忘れられていた依存関係が隠蔽される可能性があります。)
場合によっては、これらの依存関係は非常に微妙なものになることがあります。 たとえば、 リブツール コマンドは
コマンドラインにリストされているように「.lo」および「.la」ファイルを作成するだけでなく、
実際のオブジェクト ファイルを含む「.libs」というサブディレクトリを作成します。 防ぐために
ビルドミスがあると、makepp はリポジトリからの ".la" ファイルへのリンクを拒否します。 うまくいけば
将来の libtool のサポートはさらに強化される予定です。
コンパイルに関連する隠れた依存関係の多くは、コマンド ライン スキャナーによって検出されます。
コンパイラが一般的な Unix コンパイル フラグ (「-I」、「-D」など) を使用している場合、
通常、makepp はすべてのインクルード ファイルがどこにあるかを把握します。 そうでなければならないかもしれません
makepp が知らないファイルを作成する独自のスクリプトがある場合は注意してください
について。 正しいビルドを行うには、以下のリストを作成することが非常に重要です。 を ターゲットと依存関係
(またはスキャンによって自動的に決定されます)。
パッティング 絶対の ファイル名 に プログラム
構築されたファイルのいずれかに絶対ファイル名が含まれている場合も、リポジトリは機能しません。
(たとえば、ビルド コマンドのいずれかが絶対ファイル名を書き出す場合)。 例えば、
「.la」ファイルは、によって生成されたことが判明しました。 リブツール この性質を持っています。 (見てみると
「.la」ファイルの内容を確認すると、依存関係リストに絶対的な依存関係が含まれていることがわかります。
) この特定の問題を解決するために、makepp は「.la」ファイルをリンクしません。
リポジトリから。 それはそれらを再構築することを主張するでしょう。
避ける 連結 in 不要 ディレクトリ
リポジトリの起動が遅くなり、大量のメモリが使用されると大量のメモリを使用する可能性があります。
リポジトリ内の不要なファイル。 たとえば、自動 HTML を使用する場合、
ソース コードから何千もの ".html" ファイルを作成するドキュメント ジェネレーター。
リポジトリとして使用されるディレクトリのサブディレクトリにそれらを配置したくない場合があります。
それらを完全に別のディレクトリ ツリーに置く方がよいため、リポジトリ
メカニズムはそれらの名前をロードしません。
あまりに その他にもたくさんのグーグルの
リポジトリの欠点は、リポジトリ メカニズムがシンボリック リンクを使用することです。
は個別のファイルです (ただし、ディスク領域はほとんど使用しません)。 これは本物とは違います
リンクはありますが、ファイル システムの境界を越えることはできません。 極端な場合には、
非常に多くのシンボリック リンクを使用すると、予期されるファイルの数が枯渇する可能性があります (いわゆる
inode)、十分なスペースが残っているにもかかわらず。 この場合、システム管理者は次のことを行う必要があります。
ファイルシステムを調整します。
オーバーライド 倉庫 コピー
ローカルでファイルに変更を加えた場合、通常、makepp はこれを認識し、
リポジトリのコピーではなくローカル コピーを使用してファイルを再コンパイルします。
リポジトリを使用して中央のコード ベースを維持しており、開発者がいる場合
変更したファイルのみを含むローカル コピーを作成する場合、問題が XNUMX つあります。
開発者がローカル ビルドからファイルを削除したいが、
リポジトリにはまだ含まれていますか? 開発者がローカル コピーを削除すると、makepp は
喜んでリポジトリからコピーを入れると、ファイルがあるかのようにビルドが続行されます。
存在した。
この問題に対する XNUMX つのテクニック (残念ながら、ユーザー root ではありません) は、必要なファイルを作成することです。
次のように、読み取り不可能なビルド プロセスに含めないようにします。
chmod a-rw 除外するファイル
これにより、makepp がリポジトリからそれを組み込むことができなくなります。 Makepp にも含まれます
特別なコードを使用して、読み取り不可能なファイルがワイルドカードやパターン規則に一致しないようにします。
同様に、makepp がサブディレクトリ全体を組み込むのを防ぐには、ローカル
同じ名前だが書き込みできないディレクトリ。 makepp に無視させたい場合は、
ディレクトリ全体を削除し、それも読み取り不能にします。 (読み取り専用ディレクトリは検索されますが、
通常、その中のターゲットは構築されません)。
これを行うもう XNUMX つの方法は、XNUMX つ以上の除外オプションを指定して makepp を呼び出すことです。
mpp -R /path/to/rep --dont-read=/path/to/rep/除外されるファイル
しないでください つかいます リポジトリ の ファイル which できる 変化する！
ビルドの一部であるファイルにリポジトリを使用しないでください。 たとえば、あなたは
リポジトリを使用して、公開されているすべての .h ファイルを同じファイルに配置しようとする誘惑に駆られるかもしれません。
ディレクトリは次のようになります。
# トップレベルのメイクファイル
リポジトリ include=module1/include
リポジトリ include=module2/include
リポジトリ include=module3/include
リポジトリ include=module4/include
これはおそらく良い考えではありません。 どれか .h ファイル自体は、
プログラム (例: yacc または C ソース コードを吐き出す他のプログラム)、makepp
リポジトリ内のファイルは決して変更されないことを前提としています。 ビルドに必要な場合 include/xyz.h,
module2/include/xyz.h 実際には何らかのプログラムで生成する必要があるが、makepp は知りません。
プログラムを実行します。 あなたのすべてを注ぎ込むには、このようなテクニックを使用する方が良いです。 .h ファイル
共通のインクルード ディレクトリにコピーします。
# module1/Makeppfile
../include/%.h : include/%.h
&cp $(入力) $(出力)
# 次のこともできます (より効率的ですが、Windows では問題が発生します)。
# &ln -r $(入力) $(出力)
Makepp は、何か要求があった場合、リポジトリにたまたま存在するファイルをビルドしようとする可能性があります。
直接彼らに向けて、しかしそれは彼らを構築しません on 代わって ローカルディレクトリの。 結果
これは、リポジトリのシンボリック リンクが無効になる可能性があるため、非常に混乱する可能性があります。
リポジトリ ターゲットが古いときに使用されますが、そのターゲットは後で更新される可能性があります
ビルドで。 これを防ぐには、次のことを確認します。
リポジトリが参照される の リポジトリ パスを介して、またはリポジトリ パスが存在することを確認して
は、生成されたすべてのリポジトリ ファイルに対するローカル ルールでもあります。
異なるディレクトリにある同一ファイルの再コンパイルを回避するもう XNUMX つの方法は、
ビルド キャッシュ (詳細については、makepp_build_cache を参照)。 ビルド キャッシュには、
ファイルを変更できないという制限があります。
onworks.net サービスを使用してオンラインで makepp_repositories を使用する
