第4章 本格的な port

まず、あなたが port のディレクトリで make と 入力してから起こる一連の出来事について、 順を追って説明します。 ここを読むときには、別のウィンドウに bsd.port.mk を表示しておくと 理解の助けになるかもしれません。

しかし、 bsd.port.mk が何をしているのか 完全に理解できなくても 心配する必要はありません。 それほど多くの人が理解している というわけでは ありませんから…​。 f( ;)_

上記はデフォルトの動作です。これに加えて pre- 何とか や post- 何とか という ターゲットを定義したり、そのような名前のスクリプトを scripts サブディレクトリに置くことも可能で、 それぞれデフォルトの動作の前や後に実行されます。

たとえば、 post-extract ターゲットが Makefile に定義されていて、 scripts サブディレクトリに pre-build というファイルが置かれている場合、 post-extract ターゲットは 通常の展開動作の後に呼び出され、 pre-build スクリプトは デフォルトのコンパイル動作の前に実行されます。 実行する動作が簡単であれば、スクリプトよりも Makefile のターゲットを使用することが 推奨されています。 なぜなら、その port では どのような非標準の動作が必要とされるのか、 一箇所にまとめて書いてあった方が他の人に理解しやすいからです。

デフォルトの動作は bsd.port.mk の do- 何とか という ターゲットで実行されます。 たとえば port を展開するコマンドは do-extract ターゲットに書かれています。 もしデフォルトのターゲットに不満があれば、 Makefile 中で do- 何とか という ターゲットを再定義することにより、 好きなように変更することができます。

これで、ユーザが make と 入力したときに何が起こるのかが理解できたと思います。 では、完璧な port を作成するための推奨手順を 順に見ていきましょう。

(通常の場合、) 圧縮された tar ファイルの形 ( foo.tar.gz あるいは foo.tar.Z ) で オリジナルのソースを入手して、 それを DISTDIR にコピーします。 できる限り、 主流の ソースを 使用するようにしてください。

もとの tar ファイルがどこにあるかを示すために、変数 MASTER_SITES を設定する必要があります。 主なサイトのほとんどについては省略形が bsd.sites.mk で定義されています。 これらのサイト (と付随する定義) を、ソースコード内で同じ情報が繰り返されるのを避けるために、 可能な限り使うようにしてください。 これらのサイトは時とともに変わってゆきますので、そうしないと、 関係者一同にとってメンテナンスの悪夢になってしまいます。

ネットワークへの接続の良好な FTP/HTTP サイトを 見つけることができなかったり、頭にくるような非標準的な形式しか 置いていないサイトしか見つけられないときには、 自分の管理下にあり信頼できる FTP サーバや HTTP サーバ (たとえば、あなた自身のホームページ) に置くこともできます。

そのような便利かつ信頼のおける置き場所が見つからない場合、 我々が ftp.FreeBSD.org に "置き場所"を提供することもできますが、 これはなるべく避けたい解決法です。 配布ファイルは、誰かの freefall アカウントの ~/public_distfiles/ に置かれることでしょう。 その port をコミットする人に、置いてもらえるように頼んでください。 その人は配布ファイルを置いて、 MASTER_SITES を MASTER_SITE_LOCAL にセットし、 MASTER_SITE_SUBDIR には 自分の freefall ユーザ名を 入れておいてくれるでしょう。

その port の配布ファイルが、 作者によるバージョン更新のようなことがなく変更されるなら、 その配布ファイルを あなたのホームページに置いて、 MASTER_SITES の 最初に指定することも考えてみてください。できれば、その port の作者にそういうことをしないようにお願いしてみてください。 そのためには、何かしらのソースコード管理を行うと役に立つでしょう。 あなたが独自のバージョンを置けば、ユーザが checksum mismatch エラーに悩まされることもなくなりますし、FreeBSD の FTP サイトの 保守担当者の負担も減らすこともできます。 また、その port にマスターサイトが一つしか存在しない場合には、 あなたのサイトにバックアップを置き、 それを MASTER_SITES の 2 番目に 指定すると良いでしょう。

その port がインターネット上で入手できる追加パッチを 必要とするのなら、それも取ってきて DISTDIR に置いてください。 それらがメインのソースの tar ファイルとは別のサイトに あったとしても、心配する必要はありません。 そのような状況にも ちゃんと対応できるようになっています (後述の PATCHFILES の記述 を ご覧ください)。

作業用のディレクトリに tar ファイルを展開し、 最新バージョンの FreeBSD 上で正しくコンパイルするために必要な、 あらゆる変更を行ないます。 この処理は最終的に自動化するわけですから、 何を行なったかを 注意深く記録しておきましょう 。 この port が完成した暁には、ファイルの削除、追加、 修正を含むすべての処理が自動化されたスクリプトや パッチファイルで行なえるようになっていなければなりません。

その port のコンパイルやインストールのために必要な手作業が あまりに多いようならば、Larry Wall の芸術的な Configure スクリプトを 参考にしたほうが良いかもしれません。 新しい ports collection は、エンドユーザにとって個々の port が 可能な限り"プラグ & プレイ"かつ 最小のディスク消費で make できることを目指しています。

port の準備段階で追加されたり変更されたりしたファイルは、 再帰的 diff(1) により後で patch(1) に与えられる形にすることができます。 パッチは適当にまとめて patch- という名前のファイルに入れてください。 はパッチが適用される順番を示します - これらは アルファベット順 、 つまり aa が最初、 ab が その次といった順番で処理されます。 お望みなら、 patch-Imakefile とか patch-src-config.h のように、 パッチ対象のファイルのパス名を示す名前を使うこともできます。 これらのファイルは PATCHDIR に置いてください。 そうすれば自動的に適用されるようになっています。 すべてのパッチは WRKSRC からの相対パスにするべきです (通常、 WRKSRC は port の tar ファイルが展開されるディレクトリで、 make が実行されるところと同じです)。 修正やアップグレードを容易にするため、 複数のパッチで同じファイルを修正するのは避けてください (たとえば、 patch-aa と patch-ab が共に WRKSRC/foobar.c を修正するなど)。

RCS にとって特別な意味を持つ文字列をパッチ内に入れないようにしてください。 ファイルを私たちのソースツリーに入れる時、 これらの文字列は CVS によって書き換えられてしまい、 後でまたパッチを使おうとした時にうまくいかないことがあります。 RCS 文字列はドル記号 ( $ ) で囲まれており、 $FreeBSD や $RCS などで始まります。

diff(1) の再帰 ( -r ) フラグを使って再帰的なパッチを作るのは大変結構なのですが、 でき上がったパッチは必ず目でチェックして余計なゴミが入っていないことを確認してください。 よくあるのはバックアップファイル同士の変更点、あるいは Imake や GNU configure を使うソフトウェアの Makefile の変更点が入っている場合などです。 また configure.in を編集して autoconf を使って configure を作り直すときには、 configure の diff は含めずに (それらは良く数千行におよぶことがあります)、 USE_AUTOCONF=yes を定義して configure.in の diff をとってください。

ファイルをまるごと消す場合には、 パッチを使わずに post-extract ターゲットで消す方が簡単です。 できあがった差分に満足したら、 それらをソースのファイルごとに別々のパッチファイルに分割してください。

カスタマイズのために追加したいコマンドがあれば、 configure という名前のスクリプトに入れて scripts サブディレクトリに置いてください。 上で述べたように、 pre-configure あるいは post-configure という Makefile ターゲットや、 スクリプトで処理することもできます。

もし、その port がビルド、コンフィグレーション、または インストールの際にユーザからの入力を必要とするならば、 Makefile 中で IS_INTERACTIVE を設定しなければなりません。 これにより、ユーザが環境変数 BATCH を セットしている場合には、この port の処理がスキップされるので "夜間の無人ビルド" が実行可能になります。 (逆に環境変数 INTERACTIVE がセットされていると、 ユーザからの入力を必要とする port だけ が コンパイルされます)。 これは、連続して ports をビルドするマシン群で、 無駄になる時間を大きく減らします。

もし、適切なデフォルト設定が存在するのであれば、 PACKAGE_BUILDING 変数をチェックして、 それが設定されている場合には ユーザ入力のスクリプトを起動しないようにしてください。 こうすることによって、我々 ports 管理者が CDROM や FTP に 置く package を作成することができます。