第5章 Makefile の作成

PORTNAME には port の名前の基幹部分を入れ、 PORTVERSION には port のバージョン番号を入れます。

二つのオプション変数 PKGNAMEPREFIX と PKGNAMESUFFIX は、 PORTNAME および PORTVERSION と結合され、 PKGNAME を ${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION} として定義します。 この時、適切な package 名を選ぶための ガイドラインに沿っているかどうかを確認してください。 特に、PORTVERSION 中に ハイフン (-) を使用することは禁止されています。 また、package 名に language- もしくは -compiled.specifics 部分が 含まれる場合、それぞれ PKGNAMEPREFIX と PKGNAMESUFFIX を使用してください。 これらを PORTNAME の一部としてはいけません。

package の名前は以下のルールにしたがってつけてください。 これは package のディレクトリを見やすくするためで、 既に何千ものパッケージがありますし、 目を痛めてしまうようだとユーザはそっぽを向くでしょう。

package の名前は以下のようにしてください。 言語-名前-オプションバージョン.番号

package 名は ${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION} というように定義されています。 変数がこの書式と適合していることを確認してください。

では、DISTNAMEを正しい PKGNAME に直す例を見てみましょう:

以下は、ソフトウェアの作者が決めた名前から 適切な package 名に変換する方法を示した (実際の) 例です。

オリジナルのソースにまったくバージョン情報が見当たらず、 また原作者が新しいバージョンをリリースする可能性が低いときには、 バージョン番号として 1.0 を使えばいいでしょう (上記の piewm の例がこれにあたります)。 そうでない場合には原作者に聞くか、日付 (yyyy.mm.dd) を使うなどしてください。

パッケージが作成されると /usr/ports/packages/All に置かれ、一つ以上の /usr/ports/packages のサブディレクトリからリンクが張られます。 これらのサブディレクトリの名称は、CATEGORIES 変数で指定されます。これは、ユーザが FTP サイトや CDROM のパッケージの山から探し出すのを容易にするためのものです。 既存のカテゴリを参照して、 あなたの port にふさわしいものを選んでください。

また、このリストは、その port が ports ツリーのどこにインポートされるかも決定します。 ここに複数のカテゴリを指定すると、port のファイルは最初のカテゴリ名のサブディレクトリに置かれることになります。 適切なカテゴリの選択方法についてはカテゴリ節をご覧ください。

あなたが作成した port が、本当に既存のどのカテゴリにも当てはまらない場合には、 新たにカテゴリ名を作成することもできます。 その場合、新しいカテゴリを提案するメールを FreeBSD ports メーリングリスト 宛に送ってください。 しかし、一般的にはあなたが提案したカテゴリにあてはまる ports が一握りではすまない場合でなければ、 あなたの提案は却下されるでしょう。

ここに現在の port のカテゴリの一覧を示します。 アスタリスク(*) が付いているものは仮想 (virtual) カテゴリです - これらには対応するサブディレクトリが port ツリーにはありません。 これらは第 2 の補助的なカテゴリとして、 検索目的にしか使われません。

多くのカテゴリに重なるので、 どれを"第一"カテゴリにするかを決めなければならないことがたびたびあるでしょう。 これをうまく決めるルールがいくつかあります。 以下はその優先順のリストで、優先度の高いものから低いものの順に書いてあります。

もし、あなたがカテゴリについて自信が持てない場合には、 そのことを send-pr(1) する時に書き加えてください。 そうすればインポートする前にそれについて議論できます (もしあなたがコミッターであれば、 そのことを FreeBSD ports メーリングリスト に送って先に議論するようにしてください。 新しい port が間違ったカテゴリに import されて、 すぐ移動されることがあまりに多いのです。そうなると、 ソースリポジトリのマスターが不要で好ましくない膨れ方をしてしまいます。

DISTNAME は製作者が決めたソフトウェアの名前です。 デフォルトでは DISTNAME は ${PORTNAME}-${PORTVERSION} になりますので、 必要にな場合だけ書き換えるようにしてください。 DISTNAME は二つの場所でしか使われません。 一つ目は配布ファイルリスト (DISTFILES) のデフォルト ${DISTNAME} ${EXTRACT_SUFX} で、二つ目は配布ファイルが展開されるサブディレクトリ WRKSRC のデフォルト work/${DISTNAME} です。

元になる配布ファイルを指し示す、FTP/HTTP の URL のファイル名を除いた部分を MASTER_SITES に設定します。 最後にスラッシュ (/) をつけることをお忘れなく!

このシステム上に配布ファイルが見つからなかった場合、 make マクロは FETCH を使ってこの変数に指定されたサイトから配布ファイルを取得しようとします。

このリストには、 できれば異なる大陸に存在する複数のサイトを入れておくことが推奨されています。 これにより、広域ネットワークのトラブルに対する耐性を高めることができます。 さらに私たちは、自動的に最も近いマスタサイトを判断して、 そこから取ってくるメカニズムの導入を計画しています。 複数のサイトがあれば、この取組を大きく助けることになります。

元になる tar ファイルが X-contrib や GNU, Perl CPAN 等の有名なアーカイブサイトに置かれている場合には、 MASTER_SITE_* を使ってこれらのサイトを簡潔に (例えば MASTER_SITE_XCONTRIB とか、 MASTER_SITE_PERL_CPAN のように) 指定することができます。 MASTER_SITES を これらの変数の一つにセットし、 サイト内でのパスを MASTER_SITE_SUBDIR に指定するだけです。 以下に例を示します。

これらの変数は /usr/ports/Mk/bsd.sites.mk で定義されています。 いつでも新しい項目が追加されて行きますので、 port を提出する前に このファイルの最新版を チェックするように心掛けてください。

ユーザは /etc/make.conf 中で MASTER_SITE_* 変数を上書きすることもできます。 そうすることで、これらの有名なアーカイブそのものではなく、 好みのミラーサイトを使用することができます。

配布ファイルが 1 つで、 圧縮方式を示すのに普通と異なる接尾辞を使っていたら、 EXTRACT_SUFX を設定してください。

例えば、配布ファイルがより一般的な foo.tar.gz ではなく、 foo.tgz となっていたら、 次のように書きます。

USE_BZIP2 と USE_ZIP 変数を設定すると、EXTRACT_SUFX は必要に応じて自動的に .bz2 または .zip に設定されます。 どちらも設定されていなければ、EXTRACT_SUFX は .tar.gz に設定されます。

時々、ダウンロードするファイルの名称が port の名称とまったく似ていないことがあります。たとえば、 source.tar.gz などと名づけられていることもあるでしょう。 ほかに、ソースコードがいくつかのアーカイブに分かれていて、 そのすべてをダウンロードしなければならないならないこともあります。

この場合、DISTFILES に、ダウンロードしなければならないファイルすべてのリストを、 スペースで区切って設定してください。

明示的に設定されていない場合、 DISTFILES は ${DISTNAME}${EXTRACT_SUFX} に設定されます。

DISTFILES の一部だけを展開すべき (例えば、一方がソースコードで、もう一方は圧縮されていない文書という) 場合、展開しなければならないファイル名を EXTRACT_ONLY に設定してください。

どのDISTFILES も展開すべきではないなら、 EXTRACT_ONLY に空文字列を設定してください。

その port が配布ファイルの他に FTP や HTTP で手に入る追加パッチを必要とする場合には、 PATCHFILES にはそのパッチのファイル名を、 PATCH_SITES にはそのファイルが置かれているディレクトリの URL をセットしてください。(書き方は MASTER_SITES と同じです。)

そのパッチに記録されているファイル名に余計なパス名がついていて、 ソースツリーのトップディレクトリ (つまり WKRSRC) からの相対パスになっていない場合には、 それに応じた PATCH_DIST_STRIP を指定してください。 たとえば、パッチ内のすべてのファイル名の先頭に、余計な foozolix-1.0/ がついている場合には、 PATCH_DIST_STRIP=-p1 としてください。

これらのパッチは圧縮されていても大丈夫です。 ファイル名が .gz や .Z で終わる場合には、自動的に展開されるようになっています。

もしパッチが、ドキュメント等その他のファイルと一緒に gzip された tar ファイルで配布されている場合には、単に PATCHFILES を使うだけではうまくいきません。 このような場合には、このパッチの tar ファイルの名前と場所を DISTFILES と MASTER_SITES に追加しておきます。 それから、EXTRA_PATCHES 変数にそれらのパッチを指定すれば、 bsd.port.mk が 自動的にパッチを適用してくれます。 特に注意が必要なのは、パッチファイルを PATCHDIR ディレクトリにコピーしてはならないことです - (訳注: port が CD-ROM 上に置かれている等の場合には、) そのディレクトリには書き込みができないかもしれません。

(これはいささか"高度な話題"です。 この文書を初めて読む人は、 最初はこの節を飛ばしてもよいでしょう)。

この節は MASTER_SITES:n や MASTER_SITES_NN と呼ばれる取得方法について説明しています。 ここでは、この方式を MASTER_SITES:n と呼びます。

まず、背景を少し説明しておきましょう。OpenBSD には、DISTFILES と PATCHFILES 変数の両方に素敵な機能があります。ファイル、パッチの両方とも、 後ろに :n (n は [0-9] のどれかになります) をつけてグループを指示できます。たとえば、

OpenBSD では、配布ファイル alpha は、通常の MASTER_SITES ではなく MASTER_SITES0 に、 beta は MASTER_SITES1 に結び付けられます。

これは、正しいダウンロードサイトを際限なく探す羽目になるのを減らせる、 興味深い機能です。

DISTFILES にファイルが 2 つ指定され、MASTER_SITES が 20 サイトあって、サイトはものすごく遅く、 beta は MASTER_SITES 中のすべてのサイトに置かれていますが、 alpha は 20 番目のサイトにしかないという場合を考えてください。 メンテナがあらかじめそのことを知っていたら、 すべてのサイトを確認するのは無駄だと思いませんか? 楽しい週末のはじまりというわけにはゆきませんね。

イメージできたら、今度は DISTFILES や MASTER_SITES がもっと沢山あるのを想像してください。 "distfiles 調査マイスタ"は、 ネットワーク負荷が緩和されることを喜ぶに違いありません。

次節からは、FreeBSD におけるこのアイディアの実装について説明します。 OpenBSD の考え方を多少改良しています。

この節では、複数の配布ファイルやパッチを、 異なるサイトやサブディレクトリから細かく分けて取得する簡単な設定を示します。 ここでは、単純化した MASTER_SITES:n の使い方を説明します。ほとんどの場面ではこれで十分です。 さらに詳しいことを知りたければ、次の節をお読みください。

アプリケーションによっては、 いくつもの異なるサイトからダウンロードする複数の配布ファイルからなっているものがあります。 たとえば、Ghostscript は、中核部のプログラムと、 ユーザのプリンタに応じて使い分けられる多数のドライバファイルからなっています。 このドライバファイルの一部は中核部と共に配布されますが、 多くはさまざまなサイトからダウンロードしなければなりません。

これに対応するため、DISTFILES の各項目の後ろには、コロンと"タグ名" をつけられるようになっています。MASTER_SITES に設定されているそれぞれのサイトの末尾にも、コロンと、 そのサイトからダウンロードすべきファイルを示すためのタグを加えます。

たとえば、ソースコードが source1.tar.gz と source2.tar.gz の 2 つに分けられていて、 2 つの別のサイトからダウンロードしなければならないアプリケーションを考えてみましょう。 その port の Makefile には、各サイトに 1 つファイルがある場合の、簡単な MASTER_SITES:n の使用法 のような行があるとします。

複数の配布ファイルに同じタグがついていてもかまいません。 先ほどの例に続いて、3 番目の配布ファイル source3.tar.gz があって、 ftp.example2.com からダウンロードすべきだとしましょう。 Makefile は 各サイトに 1 つ以上ファイルがある場合の、簡単な MASTER_SITES:n の使用法 のようになります。

分かりました。 前節の例ではあなたの要求を満足できなかったわけですね。 この節では、ファイルの取得を細かく制御する仕組み MASTER_SITES:n がどう働くかと、これを利用するために ports をどう変更すればよいかを詳しく説明します。

/usr/ports/distfiles ディレクトリ内をあまり散らかさないようにしてください。 たくさんのファイルを取ってくる port や、他の port と名前の衝突が起きる恐れのあるファイル (Makefile など) がある場合には、 DIST_SUBDIR に port の名前 (${PORTNAME} か ${PKGNAMEPREFIX}${PORTNAME} を使うといいでしょう) を入れてください。すると DISTDIR がデフォルトの /usr/ports/distfiles から /usr/ports/distfiles/DIST_SUBDIR に変更され、 取ってきたファイルはすべてそのサブディレクトリの中に置かれるようになります。

また、 ファイルを取ってくるときにバックアップサイトとして使われる ftp.FreeBSD.org のディレクトリ名にもこの変数の値が使われます (Makefile の中で DISTDIR を明示的に指定した場合、 ローカルのファイルを置くところは変わりますが、 このサイトのディレクトリ名は変わりません。 必ず DIST_SUBDIR を使うようにしてください)。

その port が必要とする共有ライブラリを、この変数で指定します。 (訳注: libc 等、標準のライブラリは指定する必要がありません。) これは lib:dir:target という 組のリストです。 lib が共有ライブラリの名前、 dir が そのライブラリが見つからない場合に インストールされる port のディレクトリ、 targetが そのディレクトリで呼ばれるターゲットです。 たとえば、

と指定されていた場合、まずメジャーバージョンが 9 の jpeg 共有ライブラリがインストールされているかどうかを確認します。 インストールされていない場合には、ports ツリーの graphics/jpeg サブディレクトリに移動し、 target のコンパイルとインストールを行ないます。 target の部分は、 それが DEPENDS_TARGET (デフォルトでは install) と 等しいときには省略することができます。

この依存関係のチェックは、 extract ターゲットと install ターゲットの中で、2 回行なわれます。 (訳注: これは、その port をビルドするマシンとインストールされるマシンが違う場合、 どちらのマシンでもそのライブラリが利用できることを確認するためです)。 同様に、依存するライブラリの名前は package 中にも書き込まれていて、 pkg_add(1) 実行時にそのライブラリがユーザのシステムに存在していなければ、 自動的にインストールされます。

この port の実行時に必要となるプログラム、 またはファイルがあるときにはこの変数で指定します。これは path:dir:target という組のリストです。 path がファイルまたはプログラムの名前、 dir が それが見つからない場合にインストールされる port のディレクトリ、 target が そのディレクトリで呼ばれるターゲットです。 path の最初の文字がスラッシュ (/) の場合にはファイルかディレクトリとみなし、 存在するかどうか test -e を使ってチェックします。 そうでない場合には実行可能ファイルであると考えて、 そのプログラムがユーザのサーチパス上にあるかどうか which -s を使って確認します。

たとえば Makefile に以下のように書いてあるとします。

まず、/usr/local/etc/innd というファイルかディレクトリが存在するか確認します。 存在しない場合には、ports ツリーの news/inn というサブディレクトリで ビルドとインストールを行ないます。 さらに、wish8.0 というプログラムがユーザのサーチパス中にあるかどうか探します。 ない場合には同じく ports ツリーの x11-toolkits/tk80 というサブディレクトリでコンパイルとインストールを行ないます。

この依存関係は install ターゲット中でチェックされます。 また、pkg_add(1) によるインストールの際に、その package が依存するものがユーザのシステムに存在しない場合には自動的に追加インストールできるように、 依存するものの名前も package 中に記録されます。 target の部分が DEPENDS_TARGET と同じ場合には、 target の部分を省略することができます。

この port のビルド時に必要となるプログラム、 またはファイルがあるときにはこの変数で指定します。 RUN_DEPENDS と同様に、これは path:dir:target という組のリストです。たとえば、

と指定されていた場合、まず unzip という名前のプログラムがインストールされているかどうかを確認します。 インストールされていない場合には ports ツリーの archivers/unzip サブディレクトリに移動し、 ビルドとインストールを行ないます。

この port を取ってくるのに必要となるプログラム、 またはファイルがあるときにはこの変数で指定します。 上の二つと同様に、これは path:dir:target という組のリストです。たとえば、

と指定されていれば、ncftp2 という名前のプログラムを探します。 見つからない場合には、ports ツリーの net/ncftp2 サブディレクトリでビルドとインストールを行ないます。

この依存関係は fetch ターゲット中でチェックされます。 target の部分は、 DEPENDS_TARGET と同じ場合には省略することができます。

この変数には、この port の展開に必要な実行ファイルや、他のファイルを指定します。 前の変数と同じく、これは path:dir:target のタプルの一覧です。たとえば、

は、unzip という実行形式のファイルがあるかどうか確認し、 見つからなければ、ports ツリーの archivers/unzip サブディレクトリに降りてビルドおよびインストールを行います。

依存関係は extract ターゲットにおいて確認されます。 target 部分が DEPENDS_TARGET と同じなら、省いて構いません。

この変数は、この port がパッチを当てる際に必要とする実行ファイルや他のファイルを指定します。 前の変数と同じく、これは path:dir:target のタプルの一覧です。たとえば、

は、ports ツリーの java/jfc サブディレクトリに移動して、 ビルドおよびインストールを行います。

依存関係は、patch ターゲットにおいて確認されます。target 部分が DEPENDS_TARGET と同じなら省略して構いません。

上記のいずれにもあてはまらないような依存関係がある場合、 または他の port がインストールされているだけではなく ソースが展開されている必要がある場合には、この変数を使います。 これは上記の四つと違い、特に"確認"するものが ありませんので、 dir:target という形式のリストになります。 target の部分は DEPENDS_TARGET と同じ場合には省略することができます。

多くの ports に共通の依存関係をカプセル化するために、 いくつもの変数が存在しています。

その ports が X Window System を必要とするのであれば、 USE_XLIB=yes を定義してください (これは USE_IMAKE が定義されていれば自動的に定義されます)。 BSD make ではなく GNU make を必要とする場合には USE_GMAKE=yes を、 GNU autoconf を実行する必要がある場合には USE_AUTOCONF=yes を、 最新の qt toolkit を使用する場合には USE_QT=yes を、 perl 言語のバージョン 5 を必要とする場合には USE_PERL5=yes を定義してください (特に最後のものは重要です。 FreeBSD のバージョンにより、基本システムに perl5 が含まれていたり、いなかったりします)。

上で述べたように、依存する ports が必要になったときに呼ばれるデフォルトのターゲットは DEPENDS_TARGET で、そのデフォルトは install です。 これはユーザが使用する変数であり、 port の Makefile で定義するものではありません。 もし、その port が特別な方法で依存関係を扱う必要がある場合には、 DEPENDS_TARGET を再定義するのではなく *_DEPENDS 変数の :target 部分を使用してください。

make clean と入力したときには、 その port が依存する port も自動的に clean されます。 そうならないようにしたい場合には、 環境変数 NOCLEANDEPENDS を設定してください。KDE, GNOME や Mozilla のように、再ビルドするのに時間がかかる port に依存している場合は特に望ましいかもしれません。

無条件に他の port に依存させるには、 BUILD_DEPENDS や RUN_DEPENDS の最初のフィールドに ${NONEXISTENT} という変数を指定してください。 これは、他の port のソースが必要なときのみ使用してください。 ターゲットも指定することで、 コンパイルの時間を節約できる場合もあります。 たとえば

とすると、常に jpeg port のディレクトリに行ってソースの展開を行ないます。

あなたがやりたいことが他の方法ではできない場合以外には DEPENDS を使わないでください。 これは常に他の port の作成を行ない (さらにデフォルトでは インストールも行ない)、package まで作成します。 この動作が本当に所望のものでしたら、 それを BUILD_DEPENDS と RUN_DEPENDS に書くべきでしょう - 少なくとも意図を明確にすることができます。

巨大なアプリケーションの中には、 複数のコンフィギュレーションでビルドすることができるものがあります。 つまり、いくつもの外部ライブラリやアプリケーションの中の、 あるものが利用可能な場合に、 それを拡張機能として使用するように設定することができるということです。 それらのライブラリやアプリケーションを、 必ずしも すべてのユーザが必要としているわけではありませんので、ports システムではどのコンフィギュレーションがビルドされるべきかを port 作者が決めるために使えるフックを用意しています。 これらを適切にサポートすることにより、ユーザをハッピーにしたり、 port 1 つ分のコストで 2 つまたはそれ以上の port を提供するのと同様の効率化を行なうことが可能です。

これらのフックのうちで最も簡単に使えるものは WITHOUT_X11 でしょう。 その port が X Window System のサポートありと、 サポートなしの設定でビルドできるのであれば、 通常は X Window System サポートありでビルドするべきでしょう。 ビルド時に WITHOUT_X11 が定義されていれば、 その時は X Window System サポートなしのバージョンが ビルドされるべきです。

GNOME 環境の様々なパーツも、そのようなノブ (フック) を持っていますが、それらは幾分使いにくいものです。 Makefile 中で その目的に使用される変数は WANT_* と HAVE_* になります。 そのアプリケーションが、 以下に示されている依存ライブラリの一つについて、 サポートあり、なしの両方でビルドできる場合、 Makefile には WANT_PKG をセットする必要があります。 そして、ビルド時に HAVE_PKG が定義されていれば PKG を使うバージョンがビルドされることになります。

現在、このような形でサポートされている WANT_* 変数は、 WANT_GLIB, WANT_GTK, WANT_ESOUND, WANT_IMLIB, そして WANT_GNOME です。

Ports の構築技術は循環依存性を許容していません。 循環依存させてしまうと、たちまちどこかの誰かがインストールしている FreeBSD を駄目にしてしまい、その数はまたたく間に増えて行きます。 この問題は見付けるのが非常に難しいです。 問題がありそうな場合は、その変更を行う前に cd /usr/ports; make index を実行するようにしてください。 この処理は古いマシンではかなり遅いかもしれませんが、 (あなたも含めて) 多くの人がその処理を行って嘆くことにならずに済ませられるでしょう。

この変数は、 アプリケーションの配布ファイルが展開された時に作成されるディレクトリの名称を示します。 前の例で、(foo-1.0 ではなく) foo というディレクトリに展開されるなら、

または、

と書いてください。

その port がサブディレクトリに展開しないのであれば、 それを示すために NO_WRKSUBDIR を設定してください。