第5章 Makefile の作成

Makefile の作成は非常に単純です。 繰り返しますが、始めるまえに既存の例を見ておくことを推奨します。 また、このハンドブックには Makefile のサンプルがあります。 それを見て、Makefile 内の変数の順番や 空行を入れるところなどの参考にしてください。 そうすると他の人々にも読みやすいものとなります。

では、Makefile を設計するときに 問題となるところを順に追って見てみましょう。

5.1. オリジナルのソース

ソースは foozolix-1.2.tar.gz といった名前の 標準的な gzip された tar ファイルの形式で DISTDIR に置かれていますか? そうなっていれば、次のステップに進めます。 異なっている場合には、変数 DISTNAME, EXTRACT_CMD, EXTRACT_BEFORE_ARGS, EXTRACT_AFTER_ARGS, EXTRACT_SUFX, DISTFILES のうち いくつかを書き換える必要があります。 どれだけ変更しないといけないかは、その port の配布ファイルが どの程度標準からかけはなれているかによります (最もよくあるのは gzip ではなく普通の compress コマンドで tar ファイルが圧縮されている場合で、そのときは EXTRACT_SUFX=.tar.Z とするだけです)。

最悪の場合には、自分で do-extract ターゲットを作成して、 デフォルトを上書きすることもできます。 しかし、そこまでする必要があることはめったにないでしょう。

5.2. 名前の付け方

Port の Makefile のはじめの部分で port に名前をつけ、バージョン番号を記述し、適切なカテゴリに載せます。

5.2.1. PORTNAME および PORTVERSION

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

5.2.2. PORTREVISION および PORTEPOCH

5.2.2.1. PORTREVISION

PORTREVISION 変数は単調増加する値です。 PORTVERSION が増加した時 (つまり、 新しいオフィシャルベンダーリリースが行なわれた時) には いつでも 0 にリセットされます。 また、その値が 0 でない場合には package 名に追加されます。 PORTREVISION の変更は、(例えば pkg_version(1) 等の) 自動化ツールが、 新たな package が入手できることを示すのに使われます。

その port から作られる package の内容や構造に 大きな影響を与える変更を行なった時には、 PORTREVISION を増やしてください。

PORTREVISION を上げる必要がある変更の例:

  • セキュリティ上の脆弱性やバグを修正するため、または その port に新しい機能を追加するためのパッチの追加。

  • package のコンパイル時オプションの有効化や 無効化のための port の Makefile の変更。

  • パッキングリストの変更や、package のインストール時の 挙動の変更 (たとえば、ssh のホストキーのような package の 初期データを生成するスクリプトの変更など)。

  • その port が依存する共有ライブラリのバージョンを 上げる場合 (新しいバージョンの共有ライブラリが インストールされた後に、そのライブラリに依存していた 古い package をインストールを試みる場合、 その package は新しい libfoo.(x+1) ではなく 古い libfoo.x を探そうとするため、インストールに失敗します。 (訳注: そのため、PORTREVISION を上げた package を 作成する必要があるわけです))。

  • ひそかに port 配布ファイルの変更が行なわれ、 その機能に大きな変化があった場合。 つまり、distinfo の修正を 必要とするような配布ファイルの変更が行なわれ、 新旧のバージョンの diff -ru を取ると 些細とは言えない変更が認められるにもかかわらず、 オリジナルのバージョン番号が変更されていないことから PORTVERSION の変更は難しい場合。

PORTREVISION を上げる必要の無い変更の例:

  • 生成される package に機能の変化が起らないような port スケルトンのスタイル変更。

  • 生成される package に影響しないような MASTER_SITES その他の port に対する機能変更。

  • 誤植の修正などの些細な変更で、その package のユーザが アップグレードを必要とするほどには重要でないパッチ。

  • 以前にはコンパイルが通らなかった package を ビルド可能にするための修正 (その port が以前にビルド可能だった プラットフォームにおいて、その変更により何らかの機能的な 違いが発生しない場合に限ります)。 PORTREVISION は package の内容を反映したものなので、その package が以前にビルド可能でなかったのなら、変更を示すために、 PORTREVISION を 増やす必要はありません。

経験的な判断方法としては、ある port にコミットされた変更が (それが強化や修正によるものであれ、新しい package による 実質的な効能であれ)、アップデートすることにより、 誰もが利益を受けるような何かかどうか、また定期的に ports ツリーを更新している人に更新を強制するということに値するか自問してみることです。 もし答がイエスであれば、 PORTREVISION を上げるべきでしょう。

5.2.2.2. PORTEPOCH

ソフトウェアのベンダや FreeBSD の port 作成者は、 以前のものよりも小さい数字のバージョン番号をつけたソフトウェアをリリースするといった、 何か馬鹿げたことをすることが時々あります。 例をあげると、ある port が foo-20000801 から foo-1.0 になるといった具合です (数字として見ると 20000801 は 1 よりも大きいため、 間違って前者の方が新しいバージョンとして扱われてしまいます)。

このような場合には PORTEPOCH バージョンを増やしてください。 上のセクション 0 で説明したように、 PORTEPOCH がゼロでない場合には、 それがパッケージ名の後ろにつけられます。絶対に PORTEPOCH を減らしたり、ゼロにリセットしてはいけません。 さもないと、以前に作成された package との比較に失敗する (つまり、その package が古くなっていることがわからない) ためです: 新しいバージョン番号 (上の例では1.0,1) は 依然として前のバージョン番号 (20000801) よりも 数字としては小さいのですが、自動化ツールが サフィックス ,1 を特別扱いすることで、 以前の package には明示されていないサフィックス ,0 よりも新しいことがわかります。

誤って PORTEPOCH を削除したりリセットしたりすると、終わりのない悲劇に見舞われます。 上記の議論を理解できないなら、 わかるまで議論をたどるかメーリングリストで質問してください。

大多数の ports では、PORTEPOCH が 必要になることは まず無いものと考えられています。 また、注意深く PORTVERSION を使用することで、 そのソフトウェアの将来のリリースがバージョン構造を変更する必要が出てきた場合にも、 多くの場合前もって対応しておくことができるでしょう。 しかし、"スナップショット"リリースのように、 オフィシャルなバージョン番号を持たないベンダーリリースが行なわれた時には、 FreeBSD 版の port 作者によるケアが必要になります。 そういったリリースに対し、 リリース日付を使ったラベルを付けたいという誘惑にかられることがあるでしょうが、 そうすると新しい"オフィシャル"リリースが行なわれた時に、 上の例で示したような問題が起きることでしょう。

例えば、あるソフトウェアのスナップショットリリースが 20000917 に行なわれ、以前のバージョン番号が 1.2 だったとすると、 そのスナップショットの PORTVERSION には 20000917 ではなく 1.2.20000917 か何か、そのような番号を 指定するのが良いでしょう。 そうしておけば、例えばバージョン番号 1.3 として後続のリリースが 行なわれた場合にも、大小関係が崩されずにすむわけです。

5.2.2.3. PORTREVISIONPORTEPOCH の使い方の例

gtkmumble の port, バージョン 0.10 が ports collection にコミットされます。

PORTNAME=       gtkmumble
PORTVERSION=    0.10

PKGNAMEgtkmumble-0.10 になります。

ローカルな FreeBSD パッチを必要とする セキュリティホールが発見されました。 それに合わせて PORTREVISION を増やします。

PORTNAME=       gtkmumble
PORTVERSION=    0.10
PORTREVISION=   1

PKGNAMEgtkmumble-0.10_1 になります。

ベンダから 0.2 という番号が振られた 新バージョンがリリースされます (これにより、 作者は 0.10 という番号を "0.9 の次という意味ではなく"、 実際には 0.1.0 のつもりで 使用していたことがわかります - あらら、今さら遅すぎる)。 新しいマイナーバージョン 2 は数字として以前のバージョン番号 10 より小さいので、 強制的に新しい package "の方が新しい"と認識させるため PORTEPOCH を増やす必要があります。 これは新しいベンダーリリースなので、 PORTREVISION は 0 にリセット (または Makefile から削除) されます。

PORTNAME=       gtkmumble
PORTVERSION=    0.2
PORTEPOCH=      1

PKGNAMEgtkmumble-0.2,1 になります。

次のリリースは 0.3 です。 PORTEPOCH は減少することが無いため、 今度のバージョン変数は次のようになります:

PORTNAME=       gtkmumble
PORTVERSION=    0.3
PORTEPOCH=      1

PKGNAMEgtkmumble-0.3,1 になります。

もし、このアップグレードによって PORTEPOCH0 に リセットされたとすると、3 は数字として 10 よりも小さいため、 gtkmumble-0.10_1 の package をインストールした誰かは gtkmumble-0.3 の package の方が新しいことに気がつかないことになるでしょう。 これが、そもそも PORTEPOCH が導入された肝心な理由です。

5.2.3. PKGNAMEPREFIX および PKGNAMESUFFIX

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

5.2.4. package 名についての規則

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

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

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

  1. FreeBSD はユーザの慣れ親しんだ言語のサポートに力を入れています。 特定の言語のための port の package 名には 言語- に ISO-639 で定義されている言語名の略称を入れてください。 たとえば日本語なら ja、 ロシア語なら ru、 ベトナム語なら vi、 中国語なら zh、 韓国語ならば ko、 ドイツ語なら de といった具合です。

    port がある言語地域に特化したものである場合には、 さらに二文字の国名コードを付加してください。 たとえば合衆国英語圏は en_US となり、 スイスのフランス語圏は fr_CH となります。

    言語- 部分は、 PKGNAMEPREFIX 変数に 定義されなければなりません。

  2. 名前の部分の最初の文字は 小文字でなければなりません。 (名前の残りの部分は大文字を含んでいても構わないため、 大文字を含んだソフトウェア名を変換する際の規則は、 あなた自身の裁量に任されています。) perl 5 のモジュールでは先頭に p5- を付け、 二重コロン (::) のセパレータをハイフン (-) に置きかえる習慣になっています。 たとえば Data::Dumperp5-Data-Dumper になります。 また、そのソフトウェアの名前として通常使われるものに番号、 ハイフン、あるいは下線が入っている場合には、 それらを使うことも構いません (kinput2など)。

  3. コンパイル時に環境変数や make の引数などでハードコードされたデフォルトを変えてコンパイルできる場合、 -compiled.specifics にそのコンパイル時のデフォルトを入れてください (ハイフンはあってもなくてもかまいません)。 用紙のサイズ、あるいはフォントの解像度などがこれにあたります。

    -compiled.specifics 部分は、 PKGNAMESUFFIX 変数に定義されなければなりません。

  4. バージョン番号は数字とアルファベットからなり、 ピリオド (.) で区切ります。 アルファベットは二文字以上続けてはいけません。 唯一の例外は"パッチレベル"を意味する文字列 pl で、 それ以外にバージョン番号がまったくついていない場合にのみ使うことができます。 もしソフトウェアのバージョンに "alpha", "beta", "rc" や "pre" といった文字列が含まれるなら、 ピリオドの後に最初の一文字をとってください。 これらの後に、さらにバージョン文字列が続く場合には、 一文字のアルファベットの後にピリオドをつけずに番号を続けます。

    この考え方は、 バージョン文字列を見て簡単に ports を並べられるようにするためのものです。 特に、バージョン番号の各部分が必ずピリオドで区切られていること、 また日付の部分がバージョン文字列の一部となっている場合には yyyy.mm.dd という書式を使っていることを確認してください。 dd.mm.yyyy や、2000 年問題に対応していない yy.mm.dd という書式を使ってはいけません。

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

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

配布名PKGNAMEPREFIXPORTNAMEPKGNAMESUFFIXPORTVERSION理由

mule-2.2.2

(空)

mule

(空)

2.2.2

変更の必要はありません

XFree86-3.3.6

(空)

XFree86

(空)

3.3.6

変更の必要はありません

EmiClock-1.0.2

(空)

emiclock

(空)

1.0.2

プログラム一つだけの時は小文字のみ

rdist-1.3alpha

(空)

rdist

(空)

1.3.a

alpha のような文字列は使えない

es-0.9-beta1

(空)

es

(空)

0.9.b1

alpha のような文字列は使えない

mailman-2.0rc3

(空)

mailman

(空)

2.0.r3

rc のような文字列は使えない

v3.3beta021.src

(空)

tiff

(空)

3.3

なんなんでしょう ;)

tvtwm

(空)

tvtwm

(空)

pl11

バージョン番号は必ず必要

piewm

(空)

piewm

(空)

1.0

同上

xvgr-2.10pl1

(空)

xvgr

(空)

2.10.1

pl が使えるのは、 他にメジャー/マイナーバージョン番号がない場合のみ

gawk-2.15.6

ja-

gawk

(空)

2.15.6

日本語バージョン

psutils-1.13

(空)

psutils

-letter

1.13

コンパイル時に用紙のサイズを指定

pkfonts

(空)

pkfonts

300

1.0

300dpiフォント用の package

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

5.3. カテゴリ分類

5.3.1. CATEGORIES

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

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

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

時々、カテゴリを 2 階層構造や、 何か他のキーワードを利用した構造に再構成することを提案する人がいます。 今日まで、その提案はどれも実現しませんでした。 なぜなら、その構成を実現することは簡単なのですが、既存の Ports Collection 全体を構成しなおしたものに合わせて改修する労力は、 控え目にいっても気が遠くなるものだからです。 こういうアイディアを送る前に、 それらの提案の歴史をメーリングリストのアーカイブで調べてください。 さらに、動作するプロトタイプを示せと言われるのに対する準備をしておきましょう。

5.3.2. 現在のカテゴリのリスト

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

仮想カテゴリでないものは、 そのサブディレクトリ内の pkg/COMMENT に一行の記述があります (例: archivers/pkg/COMMENT)。

カテゴリ説明Notes

accessibility

障害を持ったユーザの役に立つ ports

afterstep*

AfterStep ウィンドウマネージャをサポートする ports

arabic

アラビア語サポート

archivers

アーカイブ用ツール

astro

天文学関連の ports

audio

サウンドをサポートする ports

benchmarks

ベンチマークユーティリティ

biology

生物学関連のソフトウェア

cad

CAD ツール

chinese

中国語サポート

comms

通信ソフトウェア

ほとんどはシリアルポート用のソフトウェア

converters

文字コード変換

databases

データベース

deskutils

コンピュータが発明される以前に机上で使われていた道具

(訳注: いわゆるデスクトップユーティリティのこと)

devel

開発ユーティリティ

単にライブラリだからというだけで、 どうしてもここに置かなければならない理由があるのでない限り、 ライブラリをここに含めないでください。

dns

DNS 関連ソフトウェア

editors

一般的なエディタ

特殊なエディタはそれぞれふさわしいセクションに入れます (たとえば数式エディタは math です)。

elisp

Emacs-lisp の ports

emulators

他のオペレーティングシステム用のエミュレータ

端末エミュレータはここに含まれません - X ベースのものは x11 に、 テキストベースのものは機能によって commsmisc に分類されます。

finance

金融や財務会計関連のアプリケーション。

french

フランス語サポート

ftp

FTP クライアントとサーバユーティリティ

port が FTP と HTTP の両方に対応していれば、 ftp に入れ、第 2 カテゴリを www とします。

games

ゲーム

german

ドイツ語サポート

gnome*

GNOME プロジェクトの ports

graphics

グラフィックユーティリティ

haskell*

Haskell 言語関連のソフトウェア。

hebrew

ヘブライ語サポート

hungarian

ハンガリー語サポート

ipv6*

IPv6 関連のソフトウェア

irc

インターネットリレーチャット (IRC) 用ユーティリティ

japanese

日本語サポート

java

Java 言語関連のソフトウェア

kde*

K Desktop Environment (kde) プロジェクトの ports

korean

韓国語サポート

lang

プログラミング言語

linux*

Linux アプリケーションとサポートユーティリティ

lisp*

Lisp 言語関連のソフトウェア

mail

メールソフトウェア

math

数値計算ソフトウェアやその他の数学ソフトウェア

mbone

MBone アプリケーション

misc

種々のユーティリティ

基本的に他のカテゴリに属さないものです。 これは他の仮想でないカテゴリを伴わない、唯一のカテゴリです。 misc と他のカテゴリが CATEGORIES 行に書かれている場合、 misc を削除して他のサブディレクトリにおいて良いという意味になります。 このカテゴリに置かれた ports は見落とされやすいので、 可能な限り misc よりふさわしいカテゴリを探してください。

multimedia

マルチメディアソフトウェア

net

種々のネットワークソフトウェア

net-mgmt

ネットワーク管理ソフトウェア

news

USENET ニュースソフトウェア

offix*

OffiX suite の ports

palm

Palm™ シリーズをサポートするソフトウェア

parallel*

並列計算を行うアプリケーション

pear*

Pear PHP フレームワーク関連の ports

perl5*

実行に Perl バージョン 5 を必要とする ports

picobsd

PicoBSD をサポートするための ports

plan9*

Plan9 に由来するさまざまなソフトウェア

polish

ポーランド語サポート

portuguese

ポルトガル語サポート

print

印刷ソフトウェア

DTP 用ツール (プレビューアなど) もここに分類されます。

python*

Python 言語関連のソフトウェア

ruby*

Ruby 言語関連のソフトウェア

russian

ロシア語サポート

science

astrobiology, math 等、 他のカテゴリにはあてはまらない科学関連の ports

security

セキュリティ関連のユーティリティ

shells

コマンドラインシェル

sysutils

システムユーティリティ

tcl76*

実行に Tcl バージョン 7.6 を必要とする ports

tcl80*

実行に Tcl バージョン 8.0 を必要とする ports

tcl81*

実行に Tcl バージョン 8.1 を必要とする ports

tcl82*

実行に Tcl バージョン 8.2 を必要とする ports

tcl83*

実行に Tcl バージョン 8.3 を必要とする ports

textproc

テキスト処理ユーティリティ

DTP ツールはここではなく、print に分類されます。

tk42*

実行に Tk バージョン 4.2 を必要とする ports

tk80*

実行に Tk バージョン 8.0 を必要とする ports

tk81*

実行に Tk バージョン 8.1 を必要とする ports

tk82*

実行に Tk バージョン 8.2 を必要とする ports

tk83*

実行に Tk バージョン 8.3 を必要とする ports

tkstep80*

実行に TkSTEP バージョン 8.0 を必要とする ports

ukrainian

ウクライナ語サポート

vietnamese

ベトナム語サポート

windowmaker*

WindowMaker ウィンドウマネージャをサポートする ports

www

World Wide Web 関連のソフトウェア

HTML 言語サポートもここに分類されます。

x11

X ウィンドウシステムとその関連ソフトウェア

このカテゴリは、 直接ウィンドウシステムをサポートするソフトウェアのみを対象とするものです。 通常の X アプリケーションをここに分類しないでください。 ほとんどは他の x11-* カテゴリ (下記参照) に分類されるべきです。 あなたの port が X アプリケーションで、 USE_XLIB を定義し (USE_IMAKE を定義すると自動的に定義されます)、 適切なカテゴリに分類してください。

x11-clocks

X11 用時計

x11-fm

X11 用ファイルマネージャ

x11-fonts

X11 フォントとフォントユーティリティ

x11-servers

X11 サーバ

x11-toolkits

X11 ツールキット

x11-wm

X11 ウィンドウマネージャ

zope*

Zope サポート

5.3.3. 適切なカテゴリの選択

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

  • 言語特有のカテゴリがまず最初です。 たとえば日本語の X11 のフォントをインストールする port の場合、 CATEGORIES 行は japanese x11-fonts となるでしょう。

  • より特徴的なカテゴリが、 一般的なカテゴリより優先されます。 たとえば、HTML エディタの場合は www editors となります。 これを逆順にはしないでください。 また、 port が irc, mail, mbone, news, security, www のいずれかに属する場合には net は暗黙のうちに含まれますので、入れるべきではありません。

  • x11 を第二カテゴリにするのは第一カテゴリが自然言語の場合のみにしてください。 特に X のアプリケーションには x11 を指定しないでください。

  • Emacs のモードは、 そのモードで対応しているアプリケーションと同じ ports カテゴリに置くようにして、 editors には置かないでください。 例えば、あるプログラミング言語のソースファイルを編集するための Emacs モードは、 lang に置くべきです。

  • もし、あなたの port が他のどのカテゴリにも属しない場合には misc にしてください。

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

5.4. 配布ファイル

Makefile の第二の部分では、 その port をビルドするためにダウンロードしなければならないファイルと、 それをどこからダウンロードできるか説明しています。

5.4.1. DISTNAME

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

PKGNAMEPREFIXPKGNAMESUFFIXDISTNAME に影響を与えません。 また、元のソースアーカイブが ${PORTNAME}-${PORTVERSION}${EXTRACT_SUFX} という 名前ではないのに、WRKSRCwork/${PORTNAME}-${PORTVERSION} と設定しているなら、おそらく DISTNAME はそのままにしておく必要があることに注意してください - DISTNAMEWRKSRC の両方を (そして おそらく EXTRACT_SUFX も) セットするよりは、DISTFILES を定義する方が楽でしょう。

5.4.2. MASTER_SITES

元になる配布ファイルを指し示す、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 に指定するだけです。 以下に例を示します。

MASTER_SITES=         ${MASTER_SITE_XCONTRIB}
MASTER_SITE_SUBDIR=   applications

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

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

5.4.3. EXTRACT_SUFX

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

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

DISTNAME=      foo
EXTRACT_SUFX=  .tgz

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

EXTRACT_SUFXDISTFILES を両方設定する必要はありません。

5.4.4. DISTFILES

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

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

DISTFILES=     source1.tar.gz source2.tar.gz

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

5.4.5. EXTRACT_ONLY

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

DISTFILES=     source.tar.gz manual.html
EXTRACT_ONLY=  source.tar.gz

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

EXTRACT_ONLY=

5.4.6. PATCHFILES

その 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 ファイルの名前と場所を DISTFILESMASTER_SITES に追加しておきます。 それから、EXTRA_PATCHES 変数にそれらのパッチを指定すれば、 bsd.port.mk が 自動的にパッチを適用してくれます。 特に注意が必要なのは、パッチファイルを PATCHDIR ディレクトリにコピーしてはならないことです - (訳注: port が CD-ROM 上に置かれている等の場合には、) そのディレクトリには書き込みができないかもしれません。

それが普通の gzip か compress された tar ファイルであれば、 通常のソースファイルと一緒にパッチ適用時までに展開されていますので、 明示的に展開する必要はありません。 もしパッチを DISTFILES に追加した場合には、パッチを含むファイルが展開される際に、 そのディレクトリにある何かを上書きしないように注意してください。 さらに、コピーされたパッチファイルを削除するコマンドを pre-clean ターゲットに追加することを忘れないでください。

5.4.7. 異なるサイトやサブディレクトリからの複数の配布ファイルまたはパッチ (MASTER_SITES:n)

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

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

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

DISTFILES=      alpha:0 beta:1

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

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

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

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

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

5.4.8. 簡単な説明

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

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

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

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

例 1. 各サイトに 1 つファイルがある場合の、簡単な MASTER_SITES:n の使用法
MASTER_SITES=   ftp://ftp.example1.com/:source1 \
                ftp://ftp.example2.com/:source2
DISTFILES=      source1.tar.gz:source1 \
                source2.tar.gz:source2

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

例 2. 各サイトに 1 つ以上ファイルがある場合の、簡単な MASTER_SITES:n の使用法
MASTER_SITES=   ftp://ftp.example1.com/:source1 \
                ftp://ftp.example2.com/:source2
DISTFILES=      source1.tar.gz:source1 \
                source2.tar.gz:source2 \
                source3.tar.gz:source2

5.4.9. 詳しい説明

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

  1. 要素の末尾に :n をつけることができます。 ここで、n[^:,]+ つまり、概念上はいかなる文字と数字からなる文字列でもよいのですが、 われわれとしては、当面は [a-zA-Z_][0-9a-zA-Z_]+ に制限します。

    さらに、文字列のマッチは大文字と小文字を区別します。 つまり、nN は別の文字として扱われます。

    しかし、 default, all, ALL は特別な意味を与えられているので、 末尾に付加するのには使えません (これは、ii 項で内部的に利用されています)。 さらに、DEFAULT は特別な意味を持つ単語です (3 の項を確認してください)。

  2. :n がついた要素は、グループ n に属し、 :m がついた要素は、グループ m に属するということになります。

  3. 接尾辞がついていない要素はグループに属しません。 これは、特別なグループ DEFAULT に属しているとして扱われます。 要素の後ろに DEFAULT をつけるのは、その要素を DEFAULT とそれ以外のグループに同時に割り当てたいのでなければ、 冗長に過ぎません (5 の項を確認してください)。

    次の例はどちらも同じ意味ですが、 最初の方が好ましいです。

    MASTER_SITES=   alpha
    
    MASTER_SITES=   alpha:DEFAULT
  4. グループは相互排他ではありません。 ひとつの要素が同時に複数のグループに属することができ、 ひとつのグループには複数の要素が属することも、 何も割り当てないこともできます。 同じグループで何回も指定された要素は、 単に複数回指定された要素ということになります。

  5. ある要素を同時にいくつものグループに所属させたい時は、 カンマ演算子 (,) が使えます。

    その都度別の接尾辞をつけて繰り返すかわりに、 一度だけ接尾辞を指定して複数のグループを指定できます。 たとえば、:m,n,o と書くと、その要素はグループ m, n および o に属することを示します。

    以下の例はすべて同等ですが、 最後の形式がもっともよいでしょう。

    MASTER_SITES=   alpha alpha:SOME_SITE
    
    MASTER_SITES=   alpha:DEFAULT alpha:SOME_SITE
    
    MASTER_SITES=   alpha:SOME_SITE,DEFAULT
    
    MASTER_SITES=   alpha:DEFAULT,SOME_SITE
  6. 任意のグループ内のサイトは、 MASTER_SORT_AWK によって整列されます。 MASTER_SITESPATCH_SITES 内のすべてのグループについても同様に整列されます。

  1. グループの概念は、変数 MASTER_SITES, PATCH_SITES, MASTER_SITE_SUBDIR, PATCH_SITE_SUBDIR, DISTFILES および PATCHFILES においても、下記の文法に従って使えます。

    1. MASTER_SITES, PATCH_SITES, MASTER_SITE_SUBDIR および PATCH_SITE_SUBDIR のすべての要素はスラッシュ / 記号で終端されていなければなりません。 ある要素がどれかのグループに属しているなら、 グループの接尾辞 :n は、終端記号 / のすぐ後にこなければなりません。 MASTER_SITES:n の仕組みでは、終端記号 / があることで、 :n が要素の有効な一部である場合と、 :n がグループ n を示す場合の混同を避けることができます。 以前は、 MASTER_SITE_SUBDIRPATCH_SITE_SUBDIR 要素のいずれにおいても終端記号 / は不要だったので、互換性を保つために、 接尾辞の直前の文字が / でなければ、 要素の接尾辞が :n であっても、 グループの接尾語ではなく、 要素の有効な一部分として扱われます。 MASTER_SITE_SUBDIR における MASTER_SITES:n の詳細な使用法カンマ演算子、複数のファイル、複数のサイト、 複数のサブディレクトリと合わせた MASTER_SITES:n の詳細な使用法 の両方をご覧ください。

      例 3. MASTER_SITE_SUBDIR における MASTER_SITES:n の詳細な使用法
      MASTER_SITE_SUBDIR=     old:n new/:NEW
      • グループ DEFAULT に属するディレクトリ → old:n

      • グループ NEW に属するディレクトリ → new

      例 4. カンマ演算子、複数のファイル、複数のサイト、 複数のサブディレクトリと合わせた MASTER_SITES:n の詳細な使用法
      MASTER_SITES=   http://site1/%SUBDIR%/ http://site2/:DEFAULT \
                      http://site3/:group3 http://site4/:group4 \
                      http://site5/:group5 http://site6/:group6 \
                      http://site7/:DEFAULT,group6 \
                      http://site8/%SUBDIR%/:group6,group7 \
                      http://site9/:group8
      DISTFILES=      file1 file2:DEFAULT file3:group3 \
                      file4:group4,group5,group6 file5:grouping \
                      file6:group7
      MASTER_SITE_SUBDIR=     directory-trial:1 directory-n/:groupn \
                              directory-one/:group6,DEFAULT \
                              directory

      上の例は、次のような細かく分けた取得を実現します。 サイトは、利用される順番で挙げられています。

  2. MASTER_SITE_SOURCEFORGE のように、bsd.sites.mk で定義される特別な変数をグループに割り当てるにはどうすればよいですか?

    例 5. MASTER_SITE_SOURCEFORGE と合わせた MASTER_SITES:n の詳しい使用法
    MASTER_SITES=   http://site1/ ${MASTER_SITE_SOURCEFORGE:S/$/:sourceforge,TEST/}
    DISTFILES=      something.tar.gz:sourceforge

    something.tar.gz は、MASTER_SITE_SOURCEFORGE に含まれるあらゆるサイトから取得されます。

  3. これを PATCH* 変数と組み合わせて使うにはどうすればよいでしょうか?

    すべての例で MASTER* 変数を使っていますが、PATCH_SITES と合わせた MASTER_SITES:n の簡単な使用法 にあるように、PATCH* 変数に対してもまったく同じように働きます。

    例 6. PATCH_SITES と合わせた MASTER_SITES:n の簡単な使用法
    PATCH_SITES=    http://site1/ http://site2/:test
    PATCHFILES=     patch1:test

5.4.10. ports について何が変更され、何が変わらないのでしょうか?

  1. 現在のすべての ports はそのまま変わりません。 MASTER_SITES:n 機能のコードは、7 で述べた文法に従う :n のような形式が後ろについた要素がある場合だけ動作します。

  1. port を make する際のターゲットにも変更はありません。 checksum, makesum, patch, configure, build 等です。 もちろん、do-fetch, fetch-list, master-sites それから patch-sites は例外です。

    • do-fetch は、新しくグループ分けの接尾辞のついた DISTFILESPATCHFILES を設定します。それぞれが、対応する MASTER_SITESPATCH_SITES を利用し、さらに対応する MASTER_SITE_SUBDIRPATCH_SITE_SUBDIR を利用します。カンマ演算子、複数のファイル、複数のサイト、 複数のサブディレクトリと合わせた MASTER_SITES:n の詳細な使用法 をご覧ください。

    • fetch-list は、do-fetch と同じようにグループを利用するということを除いて、以前の fetch-list のように動作します。

    • master-sites および patch-sites は、 (古いバージョンと互換性がなくなり) DEFAULT グループの要素を返すだけになっています。 実際は、それぞれ master-sites-default および patch-sites-default というターゲットを実行します。

      さらに、 MASTER_SITESPATCH_SITES を直接確認するよりも、 master-sites-all または patch-sites-all のどちらかのターゲットを使う方がよいです。 また、将来のバージョンでも直接確認ができるかどうかは保証されていません。 これら新規 port ターゲットについては、B の項をご確認ください。

  2. 新規の port ターゲット

    1. MASTER_SITES および PATCH_SITES のそれぞれについて、 グループ n の要素を表示する master-sites-n および patch-sites-n ターゲットがあります。たとえば、 master-sites-DEFAULT および patch-sites-DEFAULT のいずれも DEFAULT グループの要素を返し、 master-sites-test および patch-sites-testtest グループの要素を返します。

  1. 以前の master-sites および patch-sites が行っていた作業を行う master-sites-all および patch-sites-all という新たなターゲットがあります。 これらのターゲットは、 すべてのグループの要素をすべてが同じグループに属しているかのように返します。 ただし、 master-sites-all および patch-sites-all のそれぞれについて、 DISTFILESPATCHFILES で定義されているグループと同じ数だけ MASTER_SITE_BACKUPMASTER_SITE_OVERRIDE を表示します。

5.4.11. DIST_SUBDIR

/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 を使うようにしてください)。

この変数は Makefile 中で明示的に指定された MASTER_SITES には影響しません。

5.5. MAINTAINER

あなたのメールアドレスをここに入れてください。 お願いします。 :-)

MAINTAINER の値は、コメント部のない単一のアドレスしか受け付けられません。 user@hostname.domain という形式を利用してください。この項目には、 あなたの本名などの説明用のテキストは一切いれないでください。 (そうしても、ただ bsd.port.mk が混乱するだけです)。そういう情報は pkg-descr に書いてください。

保守担当者 (maintainer) の責任に関する詳細説明は、 Makefile 中の MAINTAINER の セクションを参照してください。

Port のメンテナがユーザからの更新要求に (主な公休日を除いて) 2 週間返答しなかったら、 保守担当者の持ち時間が切れたとみなして、 保守担当者の明示的な了承なしに更新して構いません。 保守担当者が 3 ヶ月以内に返答しない場合は、 その保守担当者は無断で不在にしているとみなして、 問題となっている port の保守担当者を入れ替えても構いません。 例外となるは、ports 管理チーム <portmgr@FreeBSD.org> または セキュリティオフィサチーム <security-officer@FreeBSD.org> が保守しているものです。このグループが保守している port に対しては許可を得ずにコミットしてはいけません。

ports 管理チーム <portmgr@FreeBSD.org> は、何か理由があれば、 誰かを保守担当から外したり、別の方を担当者にする権利を持ちます。 セキュリティオフィサチーム <security-officer@FreeBSD.org> は、セキュリティ上の理由で、 保守担当者の権限を剥奪したり担当者を変更する権利を持ちます。

5.6. COMMENT

その port の 1 行の説明です。 コメントにはパッケージ名 (やソフトウェアのバージョン) を入れないでください。 コメントは大文字で始め、最後にピリオドは付けないでください。 たとえば、こんな具合です。

COMMENT=       A cat chasing a mouse all over the screen

Makefile 中で、 COMMENT 変数は MAINTAINER 変数の直後においてください。

COMMENT 行は、port の 1 行の要約としてユーザに示されるので、 70 文字未満に抑えるようにしてください。

5.7. 依存関係

多くの port は他の port に依存しています。 必要なものすべてがユーザのマシン上に存在することを 保証するために使用可能な、7 つの変数が用意されています。 よくあるケースのためにあらかじめ設定された依存変数に加え、 いくつかの依存関係の制御のための変数があります。

5.7.1. LIB_DEPENDS

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

LIB_DEPENDS= jpeg.9:${PORTSDIR}/graphics/jpeg:install

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

先頭の lib の部分は ldconfig -r | grep -wF への引数になります。 この変数には正規表現を入れないようにしてください。

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

5.7.2. RUN_DEPENDS

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

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

RUN_DEPENDS=   ${LOCALBASE}/etc/innd:${PORTSDIR}/news/inn \
                wish8.0:${PORTSDIR}/x11-toolkits/tk80

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

この例で、innd は実際にはプログラムです。 このように、プログラムであっても一般ユーザのサーチパスに 含まれているとは考えにくいところに置かれているものの場合には、 絶対パスで指定してください。

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

5.7.3. BUILD_DEPENDS

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

BUILD_DEPENDS=unzip:${PORTSDIR}/archivers/unzip

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

ここで言う"ビルド"とは、 ファイルの展開からコンパイルまでのすべての処理を意味します。 この依存関係は、extract ターゲットの中でチェックされます。 target の部分は、 DEPENDS_TARGET と同じ場合には省略することができます。

5.7.4. FETCH_DEPENDS

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

FETCH_DEPENDS=ncftp2:${PORTSDIR}/net/ncftp2

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

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

5.7.5. EXTRACT_DEPENDS

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

EXTRACT_DEPENDS=
	    unzip:${PORTSDIR}/archivers/unzip

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

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

この変数は、展開が働いておらず (デフォルトでは gzip を仮定しています)、 USE_* で説明されている USE_ZIPUSE_BZIP2 を使っても動かない場合にだけ使ってください。

5.7.6. PATCH_DEPENDS

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

 PATCH_DEPENDS=
	    ${NONEXISTENT}:${PORTSDIR}/java/jfc:extract

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

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

5.7.7. DEPENDS

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

5.7.8. USE_*

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

表 1. USE_* 変数
変数意味

USE_BZIP2

その port の tarball は bzip2 で圧縮されています。

USE_ZIP

その port の tarball は zip で圧縮されています。

USE_GMAKE

その port をビルドするのに gmake が必要です。

USE_PERL5

その port をビルドしてインストールするのに perl 5 が必要です。 perl に関連して設定可能な他の変数については perl の利用 をご覧ください。

USE_X_PREFIX

その port は PREFIX ではなく X11BASE にインストールされます。 X11 に関連して設定可能な他の変数については、 X11 の利用 をご覧ください。

USE_AUTOMAKE

その port のビルドに GNU automake が使われます。automake に関わる他に設定可能な変数については、 automake - autoconf および libtool の利用 をご覧ください。

USE_AUTOCONF

その port のビルドに GNU autoconf が使われます。autoconf に関わる他に設定可能な変数については、 automake - autoconf および libtool の利用 をご覧ください。

USE_LIBTOOL

その port のビルドに GNU libtool が使われます。libtool に関わる他に設定可能な変数については、 automake - autoconf および libtool の利用 をご覧ください。

GMAKE

gmakePATH に入っていない場合のフルパス

USE_BISON

その port のビルドに bison が使われます。

USE_SDL

その port のビルドや実行に SDL が使われます。 USE_SDL の使い方について、詳しくは SDL の利用 をご覧ください。

NO_INSTALL_MANPAGES

install.man ターゲットを使いません。

その 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 が含まれていたり、いなかったりします)。

5.7.9. 依存関係に関する注意

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

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

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

BUILD_DEPENDS=   ${NONEXISTENT}:${PORTSDIR}/graphics/jpeg:extract

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

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

5.7.10. オプション選択可能な依存ライブラリ

巨大なアプリケーションの中には、 複数のコンフィギュレーションでビルドすることができるものがあります。 つまり、いくつもの外部ライブラリやアプリケーションの中の、 あるものが利用可能な場合に、 それを拡張機能として使用するように設定することができるということです。 それらのライブラリやアプリケーションを、 必ずしも すべてのユーザが必要としているわけではありませんので、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 です。

5.7.11. 致命的な依存の循環

Ports ツリーに循環する依存性を持ち込まないでください!

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

5.8. 作業ディレクトリの指定

それぞれの port は作業ディレクトリに展開されるので、 作業ディレクトリは書き込み可能でなければなりません。 Ports システムは、デフォルトでは DISTFILES${DISTNAME} というディレクトリに展開されると想定します。 つまり、次のように設定していたら、

PORTNAME=      foo
PORTVERSION=   1.0

その port の配布ファイルの内容は、最上位のディレクトリが foo-1.0 で、 残りのファイルはそのディレクトリの下に置かれているということです。

そうでない場合に上書きできる変数がたくさんあります。

5.8.1. WRKSRC

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

WRKSRC=      ${WRKDIR}/foo

または、

WRKSRC=      ${WRKDIR}/${PORTNAME}

と書いてください。

5.8.2. NO_WRKSUBDIR

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

NO_WRKSUBDIR= yes

5.9. CONFLICTS

あなたが作成している package が他の packageと (ファイルの衝突や実行時の非互換性により) 共存できないのであれば、CONFLICTS 変数にその package の名称を挙げてください。 *? のようなシェルの補完が利用できます。package 名は /var/db/pkg にあるのと同じ形式で並べてください。

5.10. ビルドのメカニズム

そのソフトウェアがビルドの際に GNU make を使う場合には、USE_GMAKE=yes をセットしてください。 configure を使う場合には、 HAS_CONFIGURE=yes をセットしてください。 GNU configure を使う場合には、 GNU_CONFIGURE=yes をセットしてください (これにより HAS_CONFIGURE もセットされます)。 configure に追加の引数を渡したい場合には、 追加部分を CONFIGURE_ARGS に指定してください。 (デフォルトの引数リストは、GNU configure では --prefix=${PREFIX} に、 GNU でない configure では空リストになります。) GNU autoconf を使う場合には、 USE_AUTOCONF=yes をセットしてください。 これにより GNU_CONFIGURE もセットされ、 configure を実行する前に autoconf が実行されます。

もしそのパッケージが GNU configure を使っていて、作成された実行形式のファイルが i386-portbld-freebsd4.7-appname のような"奇妙な"名称だった場合は、さらに CONFIGURE_TARGET を上書きして、新しいバージョンの autoconf で生成されたスクリプトが要求する方法でターゲットを指定する必要があります。 MakefileGNU_CONFIGURE=yes 行のすぐ後に次の行を追加してください。

CONFIGURE_TARGET=--build=${MACHINE_ARCH}-portbld-freebsd${OSREL}

そのソフトウェアが X Window System のアプリケーションなどで、 imake を使って Imakefile から Makefile を作成する場合には、 USE_IMAKE=yes を指定してください。 そうするとコンフィグレーションステージで自動的に xmkmf -a が実行されます。 もし -a フラグが問題を引き起こすなら、 さらに XMKMF=xmkmf をセットしてください。 もし、その port が imake を使用するけれども install.man ターゲットを持たない場合には、 NO_INSTALL_MANPAGES=yes をセットしてください。 ついでに、そのソフトウェアの作者を探し出して八つ裂きにするといいでしょう。 (--#)_

そのソフトウェアの元々の Makefileall 以外のものをメインのターゲットとしている場合には、それを ALL_TARGET に指定してください。 installINSTALL_TARGET も同様です。


最終更新日: 2021年12月11日 by Sergio Carlavilla Delgado