Table of Contents
多くのパッケージは、対応する機能の組合せを変えて構築することができます。
bsd.options.mk は pkgsrc における枠組のひとつで、
このようなオプションに応じて異なるパッケージ構築方法の判断を、
汎用的に処理するものです。この枠組のなかで、利用者は、
どのようなオプションの組合せを組み込んでパッケージを構築するかを厳密に指定したり、
大域的な標準状態のオプションの組合せを適用したりすることができます。
パッケージの振舞を、オプションの枠組を使って制御したい状況は、 大きく分けて二つあります。 ひとつは、プログラム自体の構築は常におこなうものの、 そのなかのある機能を有効にするかしないかです (他のパッケージに依存させるかさせないかによって制御することがよくあります)。 もうひとつは、別のプログラムを、 そのパッケージの一部として追加するかしないかです。 後者は、一般的には、オプションの枠組を使わずに、 パッケージを分割したほうがいいでしょう。 パッケージを分割すれば、 バイナリーパッケージを別々に追加できるようになるからです。 たとえば、foo パッケージには最小限の (それがないと foo パッケージに何の意味もなくなるような) 依存性を持たせておいたうえで、 別の foo-gfoo パッケージに GTK のフロントエンドプログラム gfoo を入れておくのです。 この方法は、foo パッケージに gfoo を追加する gtk オプションを用意する方法より、 すぐれています。なぜなら、オプションの枠組を使ってしまうと、 このオプションが標準で有効な場合は、 バイナリーパッケージの利用者は gfoo 抜き版の foo を使えず、 また、標準で有効ではない場合は、 バイナリーパッケージの利用者は gfoo を使えないからです。 パッケージを分割すれば、バイナリーパッケージの利用者は、 GTK 抜き版の goo をインストールすることも、 後から gfoo をインストールする (GTK はそのときになってから取り寄せる) こともできます。 また、ソースの利用者にとっても、 foo パッケージの再構築の必要がなくなるという利点があります。
依存性が大きく変化するようなプラグインは、通常は、 オプションではなく分割したほうがよいでしょう。
パッケージを分割すると、保守の手間が増えることがよくあります。 そのパッケージの本家が分割に対応していない場合は特にそうです。 分割するかオプションにするかは、 たくさんのパッケージの細切れや、依存パッケージの大きさや、作業量に対して、 利用者がどう思うであろうか、という見地に立って判断するようにします。
さらに考慮が必要なことは、ライセンスです。フリーではない部品や、 フリーでないもの (特にプラグイン) に依存する部品は、 分割可能な限り分割するのがよいでしょう。
標準の大域的なオプションは、
PKG_DEFAULT_OPTIONS に列挙します。この値は、
そのオプションに対応しているパッケージすべてに組み込むオプションを並べたものです。
この変数は mk.conf で設定するようにします。
以下に掲げるのは、bsd.options.mk
を架空の ``wibble'' パッケージでどのように使うかを示したものです。
パッケージの Makefile に直接書くか、
別のファイル options.mk に書いて
Makefile からインクルードするか、
どちらかの方法をとります。
PKG_OPTIONS_VAR= PKG_OPTIONS.wibble
PKG_SUPPORTED_OPTIONS= wibble-foo ldap
PKG_OPTIONS_OPTIONAL_GROUPS= database
PKG_OPTIONS_GROUP.database= mysql pgsql
PKG_SUGGESTED_OPTIONS= wibble-foo
PKG_OPTIONS_LEGACY_VARS+= WIBBLE_USE_OPENLDAP:ldap
PKG_OPTIONS_LEGACY_OPTS+= foo:wibble-foo
.include "../../mk/bsd.prefs.mk"
# this package was previously named wibble2
.if defined(PKG_OPTIONS.wibble2)
PKG_LEGACY_OPTIONS+= ${PKG_OPTIONS.wibble2}
PKG_OPTIONS_DEPRECATED_WARNINGS+= \
"Deprecated variable PKG_OPTIONS.wibble2 used, use ${PKG_OPTIONS_VAR} instead."
.endif
.include "../../mk/bsd.options.mk"
# Package-specific option-handling
###
### FOO support
###
.if !empty(PKG_OPTIONS:Mwibble-foo)
CONFIGURE_ARGS+= --enable-foo
.endif
###
### LDAP support
###
.if !empty(PKG_OPTIONS:Mldap)
. include "../../databases/openldap-client/buildlink3.mk"
CONFIGURE_ARGS+= --enable-ldap=${BUILDLINK_PREFIX.openldap-client}
.endif
###
### database support
###
.if !empty(PKG_OPTIONS:Mmysql)
. include "../../mk/mysql.buildlink3.mk"
.endif
.if !empty(PKG_OPTIONS:Mpgsql)
. include "../../mk/pgsql.buildlink3.mk"
.endif
最初の節には、 このパッケージがどの構築オプションに対応しているかに関する情報があり、 標準状態を設定する必要があるオプションについてはその設定をしています。
PKG_OPTIONS_VAR は、
make(1) 変数の名前で、
利用者はその名前の変数を設定して標準のオプションを上書きすることができます。
この変数名は PKG_OPTIONS.pkgbase のように設定します。
オプションの処理をする段階では
PKGBASE は定義されていないので、
PKG_OPTIONS.${PKGBASE} と定義してはいけません。
PKG_SUPPORTED_OPTIONS
は、このパッケージが対応している構築オプションを並べたリストです。
PKG_OPTIONS_OPTIONAL_GROUPS は、
互いに排他的なオプションからなるグループの名前を並べたリストです。
各グループに含まれるオプションは、
PKG_OPTIONS_GROUP. に列挙します。
ここでは、各グループのオプションのうちもっとも特徴的な設定を先頭に書きます。
各グループに含まれるオプションは、自動的に
groupnamePKG_SUPPORTED_OPTIONS に追加されます。
PKG_OPTIONS_REQUIRED_GROUPS は、
PKG_OPTIONS_OPTIONAL_GROUPS に似ていますが、
グループに含まれるオプションをどれも選ばなかった場合には、
パッケージの構築に失敗する点が異なります。
PKG_OPTIONS_NONEMPTY_SETS は、
オプションの集合の名前を並べたリストです。
各集合からは、少なくともひとつのオプションを設定する必要があります。
各集合に含まれるオプションは、
PKG_OPTIONS_SET. に列挙します。
各集合に含まれるオプションは、自動的に
setnamePKG_SUPPORTED_OPTIONS に追加されます。
集合に含まれるオプションをひとつも設定しなかった場合、パッケージの構築に失敗します。
PKG_SUGGESTED_OPTIONS は、
標準状態で有効となる構築オプションを並べたリストです。
PKG_OPTIONS_LEGACY_VARS は、
旧式の mk.conf 変数を同等のオプションに対応づけた
“USE_VARIABLE:option”
という組合せを並べたリストです。
この組合せは、旧式の変数の大域的なリストを残すために、
“+=” を使って追加するようにします。
利用者が旧式の変数を使った場合には、警告が出ます。
PKG_OPTIONS_LEGACY_OPTS は、
名前が変更されたオプションを新しいものに対応づけた
“old-option:new-option”
という組合せを並べたリストです。
この組合せは、旧名のオプションの大域的なリストを残すために、
“+=” を使って追加するようにします。
利用者が旧名のオプションを使った場合には、警告が出ます。
PKG_LEGACY_OPTIONS は、
廃止された変数用のオプションを並べたリストです。
これは、PKG_OPTIONS_LEGACY_VARS と
PKG_OPTIONS_LEGACY_OPTS のどちらでも対処できない場合、
たとえば PKG_OPTIONS_VAR の名前が変更された場合などに使うものです。
PKG_OPTIONS_DEPRECATED_WARNINGS は、
廃止された変数やオプションが使われたことと、その代替として何を使うかについての、
警告を並べたリストです。
パッケージ側では PKG_DEFAULT_OPTIONS や、
PKG_OPTIONS_VAR による変数名を変えてはいけません。
これらはもっぱら利用者が設定するためのものです。
オプションの標準設定を提案する場合は
PKG_SUGGESTED_OPTIONS を使います。
PKG_OPTIONS_VAR は、
bsd.options.mk をインクルードする前に定義する必要があります。
PKG_SUPPORTED_OPTIONS,
PKG_OPTIONS_OPTIONAL_GROUPS,
PKG_OPTIONS_REQUIRED_GROUPS のいずれも定義されていない場合は
(実行対象のプラットフォームが、
プラットフォーム固有のオプションのどれにも対応していない場合に、
これらの影響を受ける可能性があるため)、 PKG_OPTIONS は空のリストに設定され、
パッケージがオプションの枠組を使わないように保護されます。
bsd.options.mk がインクルードされた後、
変数 PKG_OPTIONS は、
選択された構築オプションを並べたリスト
(非対応あるいは廃止されたオプションは適切に除去されています)
を値として持っています。
残りの節では、各オプション固有の処理をしています。
あるオプションが PKG_OPTIONS のリストに含まれているかどうかの確認は、
以下のようにするのが正しい方法です。
.if !empty(PKG_OPTIONS:Moption)
異なるパッケージに類似の機能を追加するオプション (あるライブラリーにオプションで対応するなど) は、 その機能に対応した全パッケージの間で共通の名前 (そのライブラリーの名前など) を使うべきです。 同じ意味のオプションをもつパッケージがすでに存在する場合は、 それと同じ名前を使ってください。
ひとつのパッケージに固有の機能を追加するオプションで、
他の (無関連の) パッケージが同じ (または類似の) オプション機能をもちそうにない場合は、
冒頭に pkgname-
一群の関連パッケージの間で、
それらに固有のオプション機能を共有している場合は、
“主たる”パッケージ名を冒頭につけた形にします
(たとえば djbware-errno-hack)。
新しいオプションを追加する場合は、
mk/defaults/options.description にそのオプションの行を追加します。
行は、タブで区切られた二つのフィールドからなります。
最初のフィールドはオプション名、
二つ目はその説明です。この説明は、完全な文章 (大文字ではじまり、ピリオドで終わる)
で、このオプションで何ができるかを説明します。たとえば、“Enable ispell
support.” とします。このファイルはオプション名でソートします。
buildlink3.mk ファイルを書くときには、
依存パッケージがどのようなオプションで構築されたかによって場合分けして、
異なる依存性を列挙する必要がある場合がよくあります。
このようなオプションの問い合わせには、
pkgsrc/mk/pkg-build-options.mk ファイルを使うようにします。
通常は、以下のように使います。
pkgbase := libpurple .include "../../mk/pkg-build-options.mk" .if !empty(PKG_BUILD_OPTIONS.libpurple:Mdbus) ... .endif
pkg-build-options.mk をインクルードしたところで、
PKG_BUILD_OPTIONS.libpurple 変数に、
libpurple パッケージの構築オプションが設定されます。これにより、
options.mk における PKG_OPTIONS
と同様に、オプションを問い合わせることができます。
詳細は、pkg-build-options.mk
ファイルをご覧ください。