Copyright © 2000 The FreeBSD Documentation Project
このハンドブックは FreeBSD の port 作成者 (porter) 向けに, 具体的な port の作成方法や注意点などをまとめたものです.
日本語版の作成は FreeBSD 日本語ドキュメンテーション プロジェクト (FreeBSD doc-jp)
が行なっています. 日本語訳および, 日本語版のみに関することは FreeBSD
日本語ドキュメンテーションプロジェクト <doc-jp@jp.FreeBSD.org> に
おいて日本語で議論されています.
文書の日本語訳に関するお問い合わせや,
文書の原文に関する問い合わせをしたいが英語が得意でないという方は, FreeBSD
日本語ドキュメンテーションプロジェクト <doc-jp@jp.FreeBSD.org>
まで日本語でコメントをお寄せください.
Redistribution and use in source (SGML DocBook) and 'compiled' forms (SGML, HTML, PDF, PostScript, RTF and so forth) with or without modification, are permitted provided that the following conditions are met:
Redistributions of source code (SGML DocBook) must retain the above copyright notice, this list of conditions and the following disclaimer as the first lines of this file unmodified.
Redistributions in compiled form (transformed to other DTDs, converted to PDF, PostScript, RTF and other formats) must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
Important: THIS DOCUMENTATION IS PROVIDED BY THE FREEBSD DOCUMENTATION PROJECT "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FREEBSD DOCUMENTATION PROJECT BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
自分で port を作ることや, 既存の port の 更新作業に興味があるのですか. それはすばらしい!
ここでは FreeBSD 用の port を作る際の ガイドラインをいくつか示します. 既存の port を更新したいと考えている場合であっても, まずこの章を読んでから, 次に Chapter 14 を読むようにしてください.
この文書では充分に詳細がわからない場合には, /usr/ports/Mk/bsd.port.mk を参照してください. このファイルは, port の Makefile が例外なくインクルードしているものです. これには細かくコメントが書かれていますので, Makefile を読むのに あまり慣れていない人でも, たくさんの情報を得ることができるでしょう. それでも解決できないような質問は, FreeBSD ports メーリングリスト にポストしてみるのも 良いでしょう.
Note: この文書では, 上書き可能な 変数 (VAR) のうち 一部のものについてだけ述べています. (すべてでは無いかもしれませんが,) ほとんどの変数は bsd.port.mk の先頭部分に記述されています. なお, このファイルは非標準のタブ設定を使用しています. Emacs や Vim は, この設定をファイルの読み込み時に認識するはずです. vi と ex では, 一旦ファイルを読み込んでから :set tabstop=4 と タイプすることで, 正しい値に設定することができます.
このセクションでは, 簡単な port の作り方について説明します. 多くの場合, これだけでは不充分ですが, まあ うまくいくかどうか試してみて損はないでしょう.
まず, 元の tar ファイルを DISTDIR に置きます. この変数の デフォルト値は /usr/ports/distfiles です.
Note: 以下の例では, そのソフトウェアが そのままコンパイル可能なものと仮定しています. つまり, FreeBSD マシンで動かすために, 変更がまったく必要ないという意味です. もし何か変更が必要な場合には, 次のセクションも 参照する必要があるでしょう.
最小限の Makefile は 次のようなものになります.
# New ports collection makefile for: oneko # Date created: 5 December 1994 # Whom: asami # # $FreeBSD$ # PORTNAME= oneko PORTVERSION= 1.1b CATEGORIES= games MASTER_SITES= ftp://ftp.cs.columbia.edu/archives/X11R5/contrib/ MAINTAINER= asami@FreeBSD.org MAN1= oneko.1 MANCOMPRESSED= yes USE_IMAKE= yes .include <bsd.port.mk>
おわかりでしょうか. $FreeBSD$ を 含む行の内容については, 気にする必要はありません. この行は, このファイルが FreeBSD の ports ツリーに 取り込まれる際に, CVS によって自動的に書き込まれます. もっと詳しい例が見たい場合には, Makefile のサンプルの セクションをご覧ください.
package にするしないに関わらず, どのような port でも 三つの記述ファイルが必要です. それは pkg-comment, pkg-descr, と pkg-plist の３つで, ファイル名が pkg- で始まっていることで 他のファイルと区別できるようになっています.
このファイルには, その port についての説明を一行で書きます. package の名前だとか, バージョン番号などを 含めてはいけません. 説明は大文字で始め, 最後にピリオドは付けないでください. たとえば, こんな具合です.
A cat chasing a mouse all over the screen
このファイルには, その port についての少し長い説明を書きます. その port が何をするのかについての, 数段落程度の簡潔な解説があれば充分です.
Note: これはマニュアルでもなければ, 使用方法やコンパイル方法に ついての細かい説明書でもありません. README ファイルや マニュアルを引用するつもりなら注意が必要です. これらは多くの場合, その port の簡潔な説明になっていなかったり, 扱いにくい形式になっていたりします. (マニュアルの場合, 行を揃えるために空白が調整されていたりします.) このソフトウェアに公式のウェブサイトがあるのなら, ここに書いてください. その際自動化ツールが正しく動作するように, ウェブサイトのうちの一つには, 先頭に WWW: をつけておいてください.
このファイルの最後に, あなたの名前を書くことが推奨されています. たとえば, こんな具合です.
This is a port of oneko, in which a cat chases a poor mouse all over the screen. : (うんぬん.) WWW: http://www.oneko.org/ - Satoshi asami@cs.berkeley.edu
このファイルには, その port によってインストールされる すべてのファイルを列挙します. このファイルは package を作る際のリストとして使われるため, ``パッキングリスト (packing list)'' とも呼ばれます. ここに書くパス名は, インストール時のプレフィックス (通常 /usr/local または /usr/X11R6) からの相対パスです. MANn 変数を 使用している場合 (使用することが推奨されています), このリストに マニュアルは入れないようにしてください.
簡単な例を載せておきましょう.
bin/oneko lib/X11/app-defaults/Oneko lib/X11/oneko/cat1.xpm lib/X11/oneko/cat2.xpm lib/X11/oneko/mouse.xpm @dirrm lib/X11/oneko
パッキングリストの詳細については, pkg_create(1) のマニュアルを参照してください.
Note: このリストには, すべてのファイルを列挙しなければ なりませんが, ディレクトリそのものは列挙する必要がありません. また, この port がインストール時に独自のディレクトリを 作成する場合には, この port が削除されるときに そのディレクトリも削除されるよう, @dirrm の行を 追加しておくのを忘れないでください.
このファイルでは, すべてのファイル名を アルファベット順にソートしておくことを推奨します. そうすることで, port を更新する際の 変更点の確認が楽になります.
パッキングリストを手作業で作成するのは, 時にとても退屈な作業になります. その port が非常に多数のファイルをインストールするとしたら, パッキングリストの 自動生成を行なえば, 時間の節約になるかもしれません.
make makesum と入力するだけで, (訳注: bsd.port.mk に書かれている) port 生成ルールに従い, 自動的に distinfo ファイルが生成されます.
package 化も含め, その port が思った通りに 動くことを確認してください. 確認の必要な重要ポイントは以下の通りです.
その port がインストールしないものが pkg-plist に含まれていないこと.
その port がインストールする, すべてのものが pkg-plist に含まれていること.
reinstall ターゲットを使うことで, その port が 何度でもインストール可能なこと.
その port が deintall される際には 後片付けをすること.
推奨されるテストの手順
make install
make package
make deinstall
pkg_add package 名
make deinstall
make reinstall
make package
package および deinstall の段階で, どんな警告 (warning) も出力されないことを確認してください. ステップ 3 の後, (訳注: その port が作成した) すべての新しい ディレクトリが正しく消去されていることを確認してください. また, ステップ 4 の後にそのソフトウェアを使用してみて, package からインストールされた場合にも正しく動作することを 確認してください.
portlint を使い, その port が FreeBSD の ガイドラインに沿っているかどうかを確認してください. portlint プログラムは ports collection に 含まれています. 特に, Makefile が 正しい形式になっているか, package の 名前が正しいかどうかをチェックするのに良いでしょう.
まず, やって良いこと悪いことの セクションを読んでください.
さて, 満足のいく port が完成したら, 残るは それを FreeBSD のメインの ports ツリーに置いて, 他の人にも使ってもらうだけです. work ディレクトリや pkgname.tgz といった package は 必要ありませんから, まずこれらを消去してください. あとは shar `find port_dir` の出力を バグレポートに入れ, send-pr(1) プログラムを使用して 送ってください (send-pr(1) についての詳細はバグ報告と 一般的な論評を参照してください). もし, 圧縮していない状態で 20KB 以上あるような port であれば, それを ひとつの tar ファイルにまとめて圧縮し, バグレポートに入れる前に uuencode(1) を使用してください (20KB 以下のものを tar ファイルにして送っても良いのですが, あまり歓迎されません). バクレポートの category は必ず ports, class は change-request としてください (レポートを confidential (機密) 指定には しないでください!). また, port 化したプログラムの短い説明文を バグレポートの ``Description'' フィールドに追加して, ``Fix'' フィールドには shar したファイル, もしくは uuencode した tar ファイルを追加するようにしてください. 後者は, ports 管理の作業をスクリプトで行なっている コミッターの助けとなります.
もう一度, オリジナルのソースファイルや work ディレクトリ, make package で作成した package が 含まれていないことを確認してください.
Note: 以前には, 新しい port を提出する際に FreeBSD の FTP サイト (ftp.FreeBSD.org) に アップロードするように お願いしていたことがあります. 現在このサイトの incoming ディレクトリは 読み出し不可になっており, アップロードは推奨されていません. たくさんの海賊版ソフトウェアがそこに置かれたためです.
わたしたちはその port をチェックし, 必要なら あなたに確認して, それをツリーへ置きます. あなたの名前は FreeBSD ハンドブックやその他のファイルの ``Additional FreeBSD contributors'' の リストにも載るでしょう. う〜ん, 素晴らしい. :-)
Note: わたしたちが作業しやすいように, 障害報告の概要 (synopsis) は適切に記述してください. たとえば新しい port の提出なら ``New port: <port の簡単な説明>'', port の更新なら ``Update port: <カテゴリ>/<port 名> <更新内容の簡単な説明>'' といった形式が歓迎されます. こういう方法で報告するように心がけていれば, あなたの報告 (PR) が すぐに誰かの目にとまる確率が ぐっと高くなるのです.
残念ながら移植がそう簡単ではなく, それを動かすために 多少の変更が必要になる場合もあるでしょう. このセクションでは, 模範的な ports の作法に従い, どのように変更を行なって動くようにするのかを 順を追って説明します.
まず, あなたが port のディレクトリで make と 入力してから起こる一連の出来事について, 順を追って説明します. ここを読むときには, 別のウィンドウに bsd.port.mk を表示しておくと 理解の助けになるかもしれません.
しかし, bsd.port.mk が何をしているのか 完全に理解できなくても 心配する必要はありません. それほど多くの人が理解している というわけでは ありませんから... f(^_^;)
まず, fetch という ターゲットが実行されます. この fetch ターゲットは, 配布ファイルがローカルの DISTDIR に 存在することを保証する役目を持っています. もし必要なファイルが DISTDIR に 存在しなければ, fetch ターゲットは Makefile で指定された MASTER_SITES 中の URL や, FreeBSD のメイン FTP サイト ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/ (ここにはバックアップとして, われわれ ports 管理者が確認した 配布ファイルを置いてあります) を探しにいきます. make を実行するマシンがインターネットに 接続されていて, 目的のファイルを FETCH で 取ってこれた場合には, それを DISTDIR に 保存します.
次に extract ターゲットが実行されます. このターゲットは DISTDIR から 配布ファイル (普通は gzip された tar ファイル) を読み込み, その内容を作業ディレクトリ WRKDIR (デフォルトでは work) に展開します.
次に patch ターゲットが実行されます. まず, PATCHFILES にパッチファイルが 指定されていれば, そのパッチを適用します. 次に, PATCHDIR ディレクトリ (デフォルトでは files サブディレクトリ) に patch-* という 名前のパッチファイルが存在すれば, これらをアルファベット順に適用します.
次に configure ターゲットが 実行されます. これには, いろいろな場合があります.
scripts/configure が 存在する場合には, そのスクリプトが実行されます.
HAS_CONFIGURE または GNU_CONFIGURE がセットされていれば, WRKSRC/configure が 実行されます.
USE_IMAKE がセットされていれば, XMKMF (デフォルトでは xmkmf -a) が 実行されます.
最後に build ターゲットが実行されます. これは作業ディレクトリ (WRKSRC) に降りていき, ビルド (コンパイル) を実行するのが役目です. USE_GMAKE がセットされていれば GNU make が使用され, セットされていなければ FreeBSD の make が 使用されます.
上記はデフォルトの動作です. これに加えて pre-何とかや post-何とかという ターゲットを定義したり, そのような名前のスクリプトを scripts サブディレクトリに置くことも可能で, それぞれデフォルトの動作の前や後に実行されます.
たとえば, post-extract ターゲットが Makefile に定義されていて, scripts サブディレクトリに pre-build というファイルが置かれている場合, post-extract ターゲットは 通常の展開動作の後に呼び出され, pre-build スクリプトは デフォルトのコンパイル動作の前に実行されます. 実行する動作が簡単であれば, スクリプトよりも Makefile のターゲットを使用することが 推奨されています. なぜなら, その port では どのような非標準の動作が必要とされるのか, 一箇所にまとめて書いてあった方が他の人に理解しやすいからです.
デフォルトの動作は bsd.port.mk の do-何とかという ターゲットで実行されます. たとえば port を展開するコマンドは do-extract ターゲットに書かれています. もしデフォルトのターゲットに不満があれば, Makefile 中で do-何とかという ターゲットを再定義することにより, 好きなように変更することができます.
Note: ``メイン''のターゲット (たとえば extract, configure, その他) は, すべての前段階が実行されていることを確認してから, 実際のターゲットやスクリプトを呼び出す以外のことは 行ないませんし, これらが変更されることも想定されていません. もし展開の方法を変更したいときには do-extract の変更によって実現し, 絶対に extract には 手を触れないでください.
これで, ユーザが make と 入力したときに何が起こるのかが理解できたと思います. では, 完璧な port を作成するための推奨手順を 順に見ていきましょう.
(通常の場合,) 圧縮された tar ファイルの形 (foo.tar.gz あるいは foo.tar.Z) で オリジナルのソースを入手して, それを DISTDIR にコピーします. できる限り, 主流のソースを 使用するようにしてください.
ネットワークへの接続の良好な FTP/HTTP サイトを 見つけることができなかったり, 頭にくるような非標準的な形式しか 置いていないサイトしか見つけられないときには, 自分の管理下にあり信頼できる FTP サーバや http サーバ (たとえば, あなた自身のホームページ) に置くこともできます. あなたが選んだサーバが MASTER_SITES に 正しく反映されていることを確認してください.
そのような便利かつ信頼のおける置き場所が見つからない場合, 我々が ftp.FreeBSD.org に 置き場所を提供することもできます. 配布ファイルは, 誰かの freefall アカウントの ~/public_distfiles/ に置かれることでしょう. その port をコミットする人に, 置いてもらえるように頼んでください. その人は配布ファイルを置いて, MASTER_SITES を MASTER_SITE_LOCAL にセットし, MASTER_SITE_SUBDIR には 自分の freefall ユーザ名を 入れておいてくれるでしょう.
その port の配布ファイルが特に理由もなく しょっちゅう変わる場合には, その配布ファイルを あなたのホームページに置いて, MASTER_SITES の 最初に指定することも考えてみてください. そうすれば, ユーザが “checksum mismatch” エラーに 悩まされることもなくなりますし, FreeBSD の FTP サイトの 保守担当者の負担も減らすこともできます. また, その port にマスターサイトが一つしか存在しない場合には, あなたのサイトにバックアップを置き, それを MASTER_SITES の 2 番目に 指定すると良いでしょう.
その port がインターネット上で入手できる追加パッチを 必要とするのなら, それも取ってきて DISTDIR に置いてください. それらがメインのソースの tar ファイルとは別のサイトに あったとしても, 心配する必要はありません. そのような状況にも ちゃんと対応できるようになっています (後述の PATCHFILES の記述を ご覧ください).
作業用のディレクトリに tar ファイルを展開し, 最新バージョンの FreeBSD 上で正しくコンパイルするために必要な, あらゆる変更を行ないます. この処理は最終的に自動化するわけですから, 何を行なったかを注意深く記録しておきましょう. この port が完成した暁には, ファイルの削除, 追加, 修正を含むすべての処理が自動化されたスクリプトや パッチファイルで行なえるようになっていなければなりません.
その port のコンパイルやインストールのために必要な手作業が あまりに多いようならば, Larry Wall の芸術的な Configure スクリプトを 参考にしたほうが良いかもしれません. 新しい ports collection は, エンドユーザにとって個々の port が 可能な限り``プラグ & プレイ''かつ 最小のディスク消費で make できることを目指しています.
Note: 明示的に記述されている場合を除き, あなたが作成して FreeBSD の ports collection に寄付したパッチファイル, スクリプトおよびその他のファイルは, 標準的な BSD の 著作権条件によりカバーされているものと見なされます.
port の準備段階で追加されたり変更されたりしたファイルは, 再帰的 diff によりパッチファイル化することができます. パッチは適当にまとめて patch-* という名前のファイルに入れてください. * は パッチが適用される順番を示します -- これらは アルファベット順, つまり aa が最初, ab が その次といった順番で処理されます. お望みなら, patch-Imakefile とか patch-src-config.h のように, パッチ対象のファイルのパス名を示す名前を使うこともできます. これらのファイルは PATCHDIR に置いてください. そうすれば自動的に適用されるようになっています. すべてのパッチは WRKSRC からの相対パスにする べきです (通常, WRKSRC は port の tar ファイルが 展開されるディレクトリで, make が実行されるところと同じです). 修正やアップグレードを容易にするため, 複数のパッチで 同じファイルを修正するのは避けてください (たとえば, patch-aa と patch-ab が共に WRKSRC/foobar.c を 修正するなど).
カスタマイズのために追加したいコマンドがあれば, configure という名前のスクリプトに入れて scripts サブディレクトリに置いてください. 上で述べたように, pre-configure あるいは post-configure という Makefile ターゲットや, スクリプトで処理することもできます.
もし, その port がビルド, コンフィグレーション, または インストールの際にユーザからの入力を必要とするならば, Makefile 中で IS_INTERACTIVE をセットしてください. これにより, ユーザが環境変数 BATCH を セットしている場合には, この port の処理がスキップされるので ``夜間の無人ビルド`` が実行可能になります. (逆に環境変数 INTERACTIVE がセットされていると, ユーザからの入力を必要とする port だけが コンパイルされます).
もし, 適切なデフォルト設定が存在するのであれば, PACKAGE_BUILDING 変数をチェックして, それが設定されている場合には ユーザ入力のスクリプトを起動しないようにしてください. こうすることによって, 我々 ports 管理者が CDROM や FTP に 置く package を作成することができます.
Makefile の作成は非常に単純です. 繰り返しますが, 始めるまえに既存の例を見ておくことを推奨します. また, このハンドブックには Makefile のサンプルがあります. それを見て, Makefile 内の変数の順番や 空行を入れるところなどの参考にしてください. そうすると他の人々にも読みやすいものとなります.
では, Makefile を設計するときに 問題となるところを順に追って見てみましょう.
ソースは 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 ターゲットを作成して, デフォルトを上書きすることもできます. しかし, そこまでする必要があることはめったにないでしょう.
PORTREVISION 変数は単調増加する値です. PORTVERSION が増加した時 (つまり, 新しいオフィシャルベンダーリリースが行なわれた時) には いつでも 0 にリセットされます. また, その値が 0 でない場合には package 名に追加されます. その port から作られる package の内容や構造に 大きな影響を与える変更を行なった時には, PORTREVISION を増やしてください.
PORTREVISION を上げる必要がある変更の例:
セキュリティ上の脆弱性やバグを修正するため, または その port に新しい機能性を追加するためのパッチの追加.
package のコンパイル時オプションの有効化や 無効化のための 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 による 実質的な効能であれ), アップデートすることにより誰かがどこかで 利益を受けるような何か かどうか自問してみることです. もし答がイエスであれば, 新しい package が利用可能になった事実を (例えば pkg_version 等の) 自動化ツールが 強調することができるように, PORTREVISION を 上げるべきでしょう.
ソフトウェアのベンダや FreeBSD の port 作成者は, 以前のものよりも小さい数字のバージョン番号をつけたソフトウェアを リリースするといった, 何か馬鹿げたことをすることが時々あります. 例をあげると, ある port が foo-20000801 から foo-1.0 になる といった具合です (数字として見ると 20000801 は 1 よりも大きいため, 間違って前者の方が新しいバージョンとして扱われてしまいます).
このような場合には PORTEPOCH バージョンを 増やしてください. 上のセクション 0 で説明したように, PORTEPOCH がゼロでない場合には, それがパッケージ名の後ろにつけられます. PORTEPOCH は減らされたり, ゼロに リセットされることはありません. さもないと, 以前に作成された package との比較に失敗する (つまり, その package が古くなっていることがわからない) ためです: 新しいバージョン番号 (上の例では1.0,1) は 依然として前のバージョン番号 (20000801) よりも 数字としては小さいのですが, 自動化ツールが サフィックス ,1 を特別扱いすることで, 以前の package には明示されていないサフィックス ",0" よりも 新しいことがわかります.
大多数の ports では, PORTEPOCH が 必要になることは まず無いものと考えられています. また, 注意深く PORTVERSION を 使用することで, そのソフトウェアの将来のリリースが バージョン構造を変更する必要が出てきた場合にも, 多くの場合 前もって対応しておくことができるでしょう. しかし, 「スナップショット」リリースのように, オフィシャルな バージョン番号を持たないベンダーリリースが行なわれた時には, FreeBSD 版の port 作者によるケアが必要になります. そういったリリースに対し, リリース日付を使ったラベルを 付けたいという誘惑にかられることがあるでしょうが, そうすると新しい「オフィシャル」リリースが行なわれた時に, 上の例で示したような問題が起きることでしょう.
例えば, あるソフトウェアのスナップショットリリースが 20000917 に行なわれ, 以前のバージョン番号が 1.2 だったとすると, そのスナップショットの PORTVERSION には 20000917 ではなく 1.2.20000917 か何か, そのような番号を 指定するのが良いでしょう. そうしておけば, 例えばバージョン番号 1.3 として後続のリリースが 行なわれた場合にも, 大小関係が崩されずにすむわけです.
gtkmumble の port, バージョン 0.10 が ports collection にコミットされます.
PORTNAME= gtkmumble PORTVERSION= 0.10
PKGNAME は gtkmumble-0.10 になります.
ローカルな FreeBSD パッチを必要とする セキュリティホールが発見されました. それに合わせて PORTREVISION を増やします.
PORTNAME= gtkmumble PORTVERSION= 0.10 PORTREVISION= 1
PKGNAME は gtkmumble-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
PKGNAME は gtkmumble-0.2,1 になります.
次のリリースは 0.3 です. PORTEPOCH は減少することが無いため, 今度のバージョン変数は次のようになります:
PORTNAME= gtkmumble PORTVERSION= 0.3 PORTEPOCH= 1
PKGNAME は gtkmumble-0.3,1 になります.
Note: もし, このアップグレードによって PORTEPOCH が 0 に リセットされたとすると, 3 は数字として 10 よりも小さいため, gtkmumble-0.10_1 の package をインストールした誰かは gtkmumble-0.3 の package の方が新しいことに 気がつかないことになるでしょう.
二つのオプション変数 PKGNAMEPREFIX と PKGNAMESUFFIX は, PORTNAME および PORTVERSION と結合され, PKGNAME を ${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION} として定義します. この時, 適切な package 名を選ぶための ガイドラインに沿っているかどうかを確認してください. 特に, PORTVERSION 中に ハイフン (-) を使用することは禁止されています. また, package 名に language- もしくは compiled.specifics 部分が 含まれる場合, それぞれ PKGNAMEPREFIX と PKGNAMESUFFIX を使用してください. これらを PORTNAME の一部としてはいけません.
DISTNAME は製作者が決めたソフトウェアの名前です. デフォルトでは DISTNAME は ${PORTNAME}-${PORTVERSION} になりますが, 必要に応じて書き換えることができます. DISTNAME は二つの場所でしか使われません. 一つ目は配布ファイルリスト (DISTFILES) のデフォルト ${DISTNAME}${EXTRACT_SUFX} で, 二つ目は配布ファイルが展開される サブディレクトリ WRKSRC のデフォルト work/${DISTNAME} です.
Note: PKGNAMEPREFIX や PKGNAMESUFFIX は DISTNAME に影響を与えません. また, 元のソースアーカイブが ${PORTNAME}-${PORTVERSION}${EXTRACT_SUFX} という 名前ではないのに, WRKSRC を work/${PORTNAME}-${PORTVERSION} と 設定している場合, おそらく DISTNAME は そのままにしておく必要があることに注意してください -- DISTNAME と WRKSRC の 両方を (そして おそらく EXTRACT_SUFX も) セットするよりは, DISTFILES を 定義する方が楽でしょう.
完成した package の実体は /usr/ports/packages/All に置かれ, 一つかそれ以上の /usr/ports/packages の サブディレクトリからのシンボリックリンクが作られます. これらのサブディレクトリの名前は CATEGORIES という 変数によって指定されます. これは, ユーザが FTP サイトや CDROM 上の package の山を 渡り歩くことを容易にするためのものです. 既存のカテゴリを見て, その port に適したものを選んでください.
このリストは, この port が port ツリーの どこに取り込まれるかも決定します. 二つ以上のカテゴリを指定した場合には, 最初のカテゴリで指定されるサブディレクトリに置かれることになります. 適切なカテゴリを選ぶ方法については, カテゴリのセクションを 参照してください.
本当にその port が現存するカテゴリのいずれにも 当てはまらない場合には, 新しいカテゴリ名を作ることもできます. その場合, 新しいカテゴリ名を提案するメールを FreeBSD ports メーリングリスト あてに 送ってください.
元になる配布ファイルを指し示す, 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_* 変数を上書きすることもできます. そうすることで, これらの有名なアーカイブそのものではなく, 好みのミラーサイトを使用することができます.
その 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 上に置かれている等の場合には,) そのディレクトリには書き込みができないかもしれません.
Note: それが普通の gzip か compress された tar ファイルであれば, 通常のソースファイルと一緒にパッチ適用時までに展開されていますので, 明示的に展開する必要はないことに注意してください. もしパッチを DISTFILES に追加した場合には, パッチを含むファイルが展開される際に, そのディレクトリにある 何かを上書きしないように注意してください. さらに, コピーされたパッチファイルを削除するコマンドを pre-clean ターゲットに追加することを 忘れないでください.
あなたのメールアドレスをここに入れてください. お願いします. :-)
保守担当者 (maintainer) の責任に関する詳細説明は, Makefile 中の MAINTAINER の セクションを参照してください.
多くの port は他の port に依存しています. 必要なものすべてがユーザのマシン上に存在することを 保証するために使用可能な, 5 つの変数が用意されています. よくあるケースのためにあらかじめ設定された依存変数に加え, いくつかの依存関係の制御のための変数があります.
その 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) と
等しいときには省略することができます.Note: 先頭の lib の部分は ldconfig -r | grep -wF への 引数になります. この変数には正規表現を入れないようにしてください.
この依存関係のチェックは, extract ターゲットと install ターゲットの中で, 2 回行なわれます. (訳注: これは, その port をビルドするマシンと インストールされるマシンが違う場合, どちらのマシンでも そのライブラリが利用できることを確認するためです.) 同様に, 依存するライブラリの名前は package 中にも書き込まれていて, pkg_add 実行時に そのライブラリが ユーザのシステムに存在していなければ, 自動的にインストールされます.
この port の実行時に必要となるプログラム, またはファイルがあるときにはこの変数で指定します. これは path:dir[:target] という 組のリストです. path がファイルまたはプログラムの名前, dir が それが見つからない場合に インストールされる port のディレクトリ, target が そのディレクトリで呼ばれる ターゲットです. path の最初の文字が スラッシュ (/) の場合には ファイルかディレクトリとみなし, 存在するかどうか test -e を使ってチェックします. そうでない場合には実行可能ファイルであると考えて, そのプログラムがユーザのサーチパス上にあるかどうか which -s を使って確認します.
たとえば Makefile に以下のように書いてあるとします.
RUN_DEPENDS= ${PREFIX}/etc/innd:${PORTSDIR}/news/inn \
wish8.0:${PORTSDIR}/x11-toolkits/tk80
まず, /usr/local/etc/innd という ファイルかディレクトリが存在するか確認します. 存在しない場合には, ports ツリーの news/inn というサブディレクトリで ビルドとインストールを行ないます. さらに, wish8.0 というプログラムが ユーザのサーチパス中にあるかどうか探します. ない場合には同じく ports ツリーの x11-toolkits/tk80 というサブディレクトリで コンパイルとインストールを行ないます.
Note: この例で, innd は実際にはプログラムです. このように, プログラムであっても一般ユーザのサーチパスに 含まれているとは考えにくいところに置かれているものの場合には, 絶対パスで指定してください.
この依存関係は install ターゲット中で チェックされます. また, pkg_add によるインストールの際に, その package が依存するものがユーザのシステムに存在しない場合には 自動的に追加インストールできるように, 依存するものの名前も package 中に記録されます. target の部分が DEPENDS_TARGET と同じ場合には, target の部分を省略することができます.
この port のビルド時に必要となるプログラム, またはファイルがあるときにはこの変数で指定します. RUN_DEPENDS と同様に, これは path:dir[:target] という 組のリストです. たとえば,
BUILD_DEPENDS=unzip:${PORTSDIR}/archivers/unzip
と指定されていた場合, まず unzip という名前の
プログラムがインストールされているかどうかを確認します. インストールされていない場合には
ports ツリーの archivers/unzip サブディレクトリに移動し,
ビルドとインストールを行ないます.Note: ここで言う``ビルド''とは, ファイルの展開から コンパイルまでのすべての処理を意味します. この依存関係は, extract ターゲットの中で チェックされます. target の部分は, DEPENDS_TARGET と同じ場合には 省略することができます.
この port を取ってくるのに必要となるプログラム, またはファイルがあるときにはこの変数で指定します. 上の二つと同様に, これは path:dir[:target] という 組のリストです. たとえば,
FETCH_DEPENDS=ncftp2:${PORTSDIR}/net/ncftp2
と指定されていれば, ncftp2 という名前の プログラムを探します.
見つからない場合には, ports ツリーの net/ncftp2
サブディレクトリで ビルドとインストールを行ないます. この依存関係は fetch ターゲット中で チェックされます. target の部分は, DEPENDS_TARGET と同じ場合には 省略することができます.
上記の四つのいずれにもあてはまらないような依存関係がある場合, または他の port がインストールされているだけではなく ソースが展開されている必要がある場合には, この変数を使います. これは上記の四つと違い, 特に``確認''するものが ありませんので, dir[:target] という形式のリストになります. target の部分は DEPENDS_TARGET と同じ場合には 省略することができます.
その 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 を設定してください.
無条件に他の port に依存させるには, BUILD_DEPENDS や RUN_DEPENDS の最初のフィールドに ${NONEXISTENT} という変数を指定してください. これは, 他の port のソースが必要なときのみ使用してください. ターゲットも指定することで, コンパイルの時間を節約できる場合もあります. たとえば
BUILD_DEPENDS= ${NONEXISTENT}:${PORTSDIR}/graphics/jpeg:extract
とすると, 常に 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 です.
そのソフトウェアがビルドの際に 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 が実行されます.
そのソフトウェアが X Window System のアプリケーションなどで, imake を使って Imakefile から Makefile を作成する場合には, USE_IMAKE=yes
を指定してください. そうするとコンフィグレーションステージで自動的に xmkmf -a が実行されます. もし -a
フラグが問題を引き起こすなら, さらに XMKMF=xmkmf
をセットしてください. もし, その port が imake
を使用するけれども install.man ターゲットを持たない場合には,
NO_INSTALL_MANPAGES=yes をセットしてください. ついでに,
そのソフトウェアの作者を探し出して八つ裂きにすると いいでしょう. (-_-#)
そのソフトウェアの元々の Makefile が all 以外のものをメインのターゲットと している場合には, それを ALL_TARGET に 指定してください. install と INSTALL_TARGET も同様です.
port を作成する場合, 考慮しなくてはいけないことが 他にもいくつかあります. このセクションでは, それらのうちでも 特によくあることについて説明します.
その port が共有ライブラリのインストールを行なう場合, make 変数 INSTALLS_SHLIB を定義してください. これにより, bsd.port.mk が post-install ターゲットの実行時に 新しいライブラリがインストールされたディレクトリ (通常は PREFIX/lib) に ${LDCONFIG} -m を実行し, 共有ライブラリキャッシュへの登録が行なわれるようになります. また, この変数が定義されている場合, 共有ライブラリを インストールしたユーザが それをすぐに使い始められるように, また, 削除の際には そのライブラリが まだ存在していると システムに誤認されないように, 適切な @exec /sbin/ldconfig -m と @unexec /sbin/ldconfig -R のペアが pkg-plist ファイルに 指定されているように扱われます.
必要であれば, 共有ライブラリがインストールされるディレクトリの リストを格納する make 変数 LDCONFIG_DIRS を 定義することにより, 新しいライブラリがインストールされる デフォルトの位置を上書きすることも可能です. 例えば, その port が共有ライブラリを PREFIX/lib/foo と PREFIX/lib/bar に インストールする場合, Makefile で 以下の記述を使用することができます:
INSTALLS_SHLIB= yes LDCONFIG_DIRS= %%PREFIX%%/lib/foo %%PREFIX%%/lib/bar
pkg-plist の他の部分と同様に, LDCONFIG_DIRS の内容も sed(1) による 処理が行なわれるため, ここでも PLIST_SUB に 指定した置換が行なわれることに注意してください. PREFIX には %%PREFIX%% を, LOCALBASE には %%LOCALBASE%%, X11BASE には %%X11BASE%% を 使用することを推奨します.
その port の変数 (たとえば解像度とか紙のサイズなど) を 変えたりした, 少しだけ違うバージョンを作成する必要があるときには, ユーザが分りやすいように package ごとに別々のサブディレクトリを作成し, できるだけ port 間でファイルを共有するようにしてください. ほとんどの場合, うまく変数を使えば, 一つを除くすべてのディレクトリには とても短い Makefile を置くだけで済みます. その短い Makefile では, MASTERDIR を使って, 残りのファイルがあるディレクトリを指定できます. また, PKGNAMESUFFIX の 一部に変数に使って, package が別々の名前を持つようにしてください.
具体的な例を示すのが一番わかりやすいでしょう. これは japanese/xdvi300/Makefile の一部です.
PORTNAME= xdvi
PORTVERSION= 17
PKGNAMEPREFIX= ja-
PKGNAMESUFFIX= ${RESOLUTION}
:
# default
RESOLUTION?= 300
.if ${RESOLUTION} != 118 && ${RESOLUTION} != 240 && \
${RESOLUTION} != 300 && ${RESOLUTION} != 400
@${ECHO} "Error: invalid value for RESOLUTION: \"${RESOLUTION}\""
@${ECHO} "Possible values are: 118, 240, 300 (default) and 400."
@${FALSE}
.endif
japanese/xdvi300 には Makefile の他に通常のパッチや, package ファイル等が置かれています. このディレクトリで make を実行すると, デフォルトの解像度 (300) を使って, 普通に port のビルドを行ないます.
他の解像度に関していうと, xdvi118/Makefile に 必要なのはこれだけです:
RESOLUTION= 118
MASTERDIR= ${.CURDIR}/../xdvi300
.include ${MASTERDIR}/Makefile
(xdvi240/Makefile や xdvi400/Makefile も同様のものになります). bsd.port.mk は, MASTERDIR の定義から FILESDIR や SCRIPTDIR 等の 通常のサブディレクトリが xdvi300 以下に 存在することを理解します. RESOLUTION=118 の行が, xdvi300/Makefile の RESOLUTION=300 の行を上書きし, port は解像度を 118 として作成されます.
まず 共有ライブラリの バージョンについての指針を読んで, 一般的に 共有ライブラリのバージョンをどうすれば良いかを理解してください. ソフトウェアの作者は自分がしていることを理解していると, 盲目的に信じていてはいけません; 多くの場合は理解していないのです. 細部にわたって注意深く考慮することは大変重要です. なぜなら我々は, 互換性がないかもしれない大量のソフトウェアを 共存させようとする特殊な状況にあるからです. むかし, 不注意な port の導入が共有ライブラリに関する重大な問題を 引き起してしまったことがあります (なぜ jpeg-6b の 共有ライブラリのバージョン番号が 9 なのか, 今まで不思議に思ったことは ありませんか?). もし疑問があれば, FreeBSD ports メーリングリスト にメールを送ってください. ほとんどの時間は正しい共有ライブラリのバージョンを決めることと, それを実現するためのパッチを作成することに終始します.
MAN[1-9LN] 変数に指定したマニュアルは 自動的に pkg-plist に追加されます (つまり, マニュアルを pkg-plist に加えては いけません-- pkg-plist の生成を参照してください). また, /etc/make.conf 中の NOMANCOMPRESS の設定に従って, インストール時に マニュアルを自動的に圧縮したり復元したりします.
その port が, シンボリックリンクやハードリンクを用いて, 複数のファイル名を持つマニュアルをインストールする場合には, それらを識別するために MLINKS 変数を 使用しなければなりません. port によってインストールされたリンクは, 意図したファイルを きちんと指しているかどうか確認するため, bsd.port.mk によって 削除されたり, 再作成されたりします. MLINKS に指定されたマニュアルも, pkg-plist に 含めてはいけません.
マニュアルをインストール時に圧縮するかどうかを 指定するには, MANCOMPRESSED 変数を使用します. この変数は yes, no そして maybe の三つの値をとることができます, yes はマニュアルが既に圧縮されてインストール されていること, no は圧縮されていないこと, maybe は既にそのソフトウェアが NOMANCOMPRESS の値に従っていて, bsd.port.mk は 特別なにもする必要がないことを意味します.
USE_IMAKE がセットされていて, NO_INSTALL_MANPAGES がセットされていなければ, MANCOMPRESSED は自動的に yes に 設定されます. それ以外の場合には, MANCOMPRESSED は no に設定されます. その port にとって, デフォルトの設定が適切でない場合以外には, 明示的に設定する必要はありません.
PREFIX 以外のディレクトリの下に マニュアルを置くような port では, そのディレクトリを MANPREFIX で指定することができます. さらに, いくつかの Perl モジュールの ports のように, 特定のセクションのマニュアルだけを非標準の場所に インストールする場合, 個々のマニュアルのパスを MANsectPREFIX (ここで sect は 1-9, L, または N のいずれか) により 指定することができます.
マニュアルが言語特有のサブディレクトリに置かれる場合には, その言語名を MANLANG に設定してください. この変数のデフォルト値は "" に なっています (つまり, 英語のみ).
これは, 全部をまとめた例です.
MAN1= foo.1
MAN3= bar.3
MAN4= baz.4
MLINKS= foo.1 alt-name.8
MANLANG= "" ja
MAN3PREFIX= ${PREFIX}/share/foobar
MANCOMPRESSED= yes
これは, この port により以下の 6 個のファイルが インストールされることを表しています.
${PREFIX}/man/man1/foo.1.gz
${PREFIX}/man/ja/man1/foo.1.gz
${PREFIX}/share/foobar/man/man3/bar.3.gz
${PREFIX}/share/foobar/man/ja/man3/bar.3.gz
${PREFIX}/man/man4/baz.4.gz
${PREFIX}/man/ja/man4/baz.4.gz
さらに ${PREFIX}/man/man8/alt-name.8.gz が この port によってインストールされるかどうかわかりませんが, それとは無関係に foo(1) と alt-name(8) のマニュアルページを指す シンボリックリンクが作成されます.
コンパイルに Motif ライブラリを必要とするアプリケーションが いくつかあります (Motif 自体は有料のものがいくつかの会社から 手に入りますし, x11-toolkits/lesstif には 多くのアプリケーションを動作させることが可能な 無料の互換ライブラリもあります). Motif は広く使われているツールキットですし, 有料のもののライセンスでも ライブラリを静的にリンクした実行形式の再配布が認められている場合が 多いので, Motif を必要とするソフトウェアを簡単に (port からコンパイルする人々のために) 動的にでも, (package を配布する人々のために) 静的にでも リンクできるような仕組みが用意されています.
Motif が無いとコンパイルできない port の Makefile では, この変数を指定してください. これにより, Motif を持っていない人が この port をコンパイルしようとするのを未然に防ぎます.
この変数は bsd.port.mk によって Motif ライブラリの指定に置き換えられます. ソース内の Makefile や Imakefile で Motif ライブラリを指定している ところを, この変数に置き換えるようにパッチを適用してください.
代表的な例としては以下の二つがあげられます:
Makefile か Imakefile の中で Motif ライブラリが -lXm
として使われている場合には, かわりに MOTIFLIB
と書いてください.
Imakefile の中で XmClientLibs が使われている場合には, それを ${MOTIFLIB} ${XTOOLLIB} ${XLIB} と書きかえてください.
なお MOTIFLIB は通常, -L/usr/X11R6/lib
-lXm か /usr/X11R6/lib/libXm.a に置き換えられます.
したがって前に -L や -l
をつける必要はありません.
もし, あなたの port が X window system のフォントをインストールするのであれば, それらを X11BASE/lib/X11/fonts/local に置くようにしてください. このディレクトリは XFree86 release 3.3.3 で新設されたものです. もしそれが存在しなければ作成し, ユーザに XFree86 を 3.3.3 かそれより新しいものに更新か, 少なくともこのディレクトリを /etc/XF86Config のフォントパスに加えるように促すメッセージを出力するようにしてください.
新しい版の texinfo (2.2.2-RELEASE およびそれ以降に入っています) には install-info というコマンドが含まれており, dir ファイルに項目を追加したり削除したりすることができます. もし, あなたの port が info 文書をインストー ルするのであれば, 以下の指示に従ってその port および package が正しくユーザの ${PREFIX}/info/dir ファイルを更新するようにしてください (このセクションはとても長くてすいません. しかし info ファイルを作りあげるためにはこれらは不可欠です. 正しく行なえば美しいリストができますので, 辛抱してください! :-)
まず, これを知っておかなければなりません.
% install-info --help
install-info [OPTION]... [INFO-FILE [DIR-FILE]]
Install INFO-FILE in the Info directory file DIR-FILE.
(訳注: Info ディレクトリの INFO-FILE を DIR-FILE にインストールする)
Options:
--delete Delete existing entries in INFO-FILE;
don't insert any new entries.
(訳注: INFO-FILE の中の項目を削除,
新しい項目は一切追加しない.)
:
--entry=TEXT Insert TEXT as an Info directory entry.
(訳注: TEXT を Info ディレクトリの項目として追加する.)
:
--section=SEC Put this file's entries in section SEC of the directory.
(訳注: このファイルの項目を Info ディレクトリの SEC
というセクションに置く.)
:
Note: このプログラムは, 実際には info ファイルをインストールしません. 単に dir ファイルにエントリを挿入したり削除したりするだけです.
これから, install-info を使用するように, ports を変換する 7 段階の工程を示します. 例として editors/emacs を使用します.
まず, texinfo のソースを見て, @dircategory と @direntry 文がないファイルについて, それらを追加するパッチを作成します. 以下は, ここでの例での patchの一部です:
--- ./man/vip.texi.org Fri Jun 16 15:31:11 1995 +++ ./man/vip.texi Tue May 20 01:28:33 1997 @@ -2,6 +2,10 @@ @setfilename ../info/vip @settitle VIP +@dircategory The Emacs editor and associated tools +@direntry +* VIP: (vip). A VI-emulation for Emacs. +@end direntry @iftex @finalout :
フォーマットについては見ればわかると思います. dir というファイルに必要な項目を書いておいてくれる作者も多いので, まず自分で書く前にさがしてみてください. また, 関係する ports も調べて, セクションの名前やインデントなどがきちんと合っているかどうかを確認してください (項目のテキスト は, すべて 4 つめのタブ・ストップ (tab stop) から始めることを推奨します).
Note: 一つのファイルに対して一つの info の項目しか書けないことに注意してください. これは install-info --delete のバグにより
<@direntry>セクションに複数の項目を書いても初めの一つの項目しか削除してくれないからです.
texinfo のソースにパッチを適用する代わりに dir の項目を install-info の引数 (--section, --entry) として与えることもできますが,
あまり良い方法とは言えません. なぜなら同じ情報を三つの場所 (Makefile, pkg-plist の @exec/@unexec: 以下参照)
に重複して書く必要があるからです. しかし, もし日本語 (あるいは, 他のマルチバイト文字)の
info ファイルがある場合には install-info
の特別な引数を使用する必要があるでしょう. なぜなら makeinfo
がこのような texinfo ソースファイルを扱えないからです.
(このようなものをどう扱うかの例としては japanese/skk の Makefile と pkg-plist
を見てください).
portのディレクトリに戻って make clean; make を実行し, info ファイルが texinfo ソースファイルから再び生成されることを確認してください. texinfo ソースファイルのほうが info ファイルよりも新しいので make と入力すれば info ファイルは再構築されるはずですが, 多くの Makefile には info ファイルの正しい依存関係が書かれていません. emacs の場合, info ファイルの再構築の際には man サブディレクトリに降りるように メインの Makefile.in に パッチを適用する必要がありました.
--- ./Makefile.in.org Mon Aug 19 21:12:19 1996
+++ ./Makefile.in Tue Apr 15 00:15:28 1997
@@ -184,7 +184,7 @@
# Subdirectories to make recursively. `lisp' is not included
# because the compiled lisp files are part of the distribution
# and you cannot remake them without installing Emacs first.
-SUBDIR = lib-src src
+SUBDIR = lib-src src man
# The makefiles of the directories in $SUBDIR.
SUBDIR_MAKEFILES = lib-src/Makefile man/Makefile src/Makefile oldXMenu/Makefile lwlib/Makefile
--- ./man/Makefile.in.org Thu Jun 27 15:27:19 1996
+++ ./man/Makefile.in Tue Apr 15 00:29:52 1997
@@ -66,6 +66,7 @@
${srcdir}/gnu1.texi \
${srcdir}/glossary.texi
+all: info
info: $(INFO_TARGETS)
dvi: $(DVI_TARGETS)
メインの Makefile からは, all として呼びたいのですが, man サブディレクトリでのデフォルトターゲットは info になっています. このため, 二つ目のパッチが必要になります. また, info info ファイルのインストールも削除しました. なぜなら, それは同じ名前ですでに /usr/share/info にあるからです (そのパッチはここでは示しません).
もし, Makefile に dir ファイルをインストールする個所があれば削除します. あなたの port がインストールしてはいけません. また, dir ファイルを壊してしまうようなコマンドの類も削除します.
--- ./Makefile.in.org Mon Aug 19 21:12:19 1996
+++ ./Makefile.in Mon Apr 14 23:38:07 1997
@@ -368,14 +368,8 @@
if [ `(cd ${srcdir}/info && /bin/pwd)` != `(cd ${infodir} && /bin/pwd)` ]; \
then \
(cd ${infodir}; \
- if [ -f dir ]; then \
- if [ ! -f dir.old ]; then mv -f dir dir.old; \
- else mv -f dir dir.bak; fi; \
- fi; \
cd ${srcdir}/info ; \
- (cd $${thisdir}; ${INSTALL_DATA} ${srcdir}/info/dir ${infodir}/dir); \
- (cd $${thisdir}; chmod a+r ${infodir}/dir); \
for f in ccmode* cl* dired-x* ediff* emacs* forms* gnus* info* message* mh-e* sc* vip*; do \
(cd $${thisdir}; \
${INSTALL_DATA} ${srcdir}/info/$$f ${infodir}/$$f; \
chmod a+r ${infodir}/$$f); \
(これは, 既存のportを修正するときのみ必要です.) pkg-plist を見て, info/dir にパッチをあてようとするものすべてを削除します. これらは pkg-install やその他のファイルにもあるかもしれないので, いろいろさがしてみてください.
Index: pkg-plist =================================================================== RCS file: /usr/cvs/ports/editors/emacs/pkg/pkg-plist,v retrieving revision 1.15 diff -u -r1.15 pkg-plist --- pkg-plist 1997/03/04 08:04:00 1.15 +++ pkg-plist 1997/04/15 06:32:12 @@ -15,9 +15,6 @@ man/man1/emacs.1.gz man/man1/etags.1.gz man/man1/ctags.1.gz -@unexec cp %D/info/dir %D/info/dir.bak -info/dir -@unexec cp %D/info/dir.bak %D/info/dir info/cl info/cl-1 info/cl-2
post-install ターゲットを Makefile に加えてインストールされた info ファイルについては, install-info を実行するようします (dir ファイルが存在しない場合にそれを作成するようにする必要はなくなりました. install-info はこのファイルが存在しなければ自動的に作成します).
Index: Makefile
===================================================================
RCS file: /usr/cvs/ports/editors/emacs/Makefile,v
retrieving revision 1.26
diff -u -r1.26 Makefile
--- Makefile 1996/11/19 13:14:40 1.26
+++ Makefile 1997/05/20 10:25:09 1.28
@@ -20,5 +20,11 @@
post-install:
.for file in emacs-19.34 emacsclient etags ctags b2m
strip ${PREFIX}/bin/${file}
.endfor
+.for info in emacs vip viper forms gnus mh-e cl sc dired-x ediff ccmode
+ install-info ${PREFIX}/info/${info} ${PREFIX}/info/dir
+.endfor
.include <bsd.port.mk>
pkg-plist を編集して, 同じ働きをする @exec 文, それに pkg_delete のために @unexec 文を加えてください.
Index: pkg-plist =================================================================== RCS file: /usr/cvs/ports/editors/emacs/pkg-plist,v retrieving revision 1.15 diff -u -r1.15 pkg-plist --- pkg-plist 1997/03/04 08:04:00 1.15 +++ pkg-plist 1997/05/20 10:25:12 1.17 @@ -16,7 +14,14 @@ man/man1/etags.1.gz man/man1/ctags.1.gz +@unexec install-info --delete %D/info/emacs %D/info/dir : +@unexec install-info --delete %D/info/ccmode %D/info/dir info/cl info/cl-1 @@ -87,6 +94,18 @@ info/viper-3 info/viper-4 +@exec install-info %D/info/emacs %D/info/dir : +@exec install-info %D/info/ccmode %D/info/dir libexec/emacs/19.34/i386--freebsd/cvtmail libexec/emacs/19.34/i386--freebsd/digest-doc
Note: @unexec install-info --delete コマンドは info ファイル自身より先に置き, コマンドがファイルを読めるようにしておかなければならないことに注意してください. また @exec install-info コマンドは, info ファイルおよび dir ファイルを作る @exec コマンドより後におかなければなりません.
テスト をして出来栄えに感服しましょう :) 各段階の前後に dir ファイルをチェックしましょう.
pkg-* ファイルには, まだ取り上げていない何かと重宝なトリックがいくつかあります.
もしインストールする人にメッセージを表示する必要がある場合には, そのメッセージを pkg-message に置くことができます. この機能は pkg_add の後の追加のインストール手続きを表示するときなどに重宝します.
Note: pkg-message ファイルは pkg-plist に加える必要はありません. また, もしユーザが package ではなく port を使用している場合には自動的には表示されませんので, 明示的に post-install で表示するようにするべきでしょう.
バイナリパッケージが pkg_add でインストールされるときに実行する必要のあるコマンドがあれば, pkg-install スクリプトを使って実行することができます. このスクリプトは自動的に package に加えられ, pkg_add によって 2 回実行されます. 1 回目は ${SH} pkg-install ${PKGNAME} PRE-INSTALL として, 2 回目には ${SH} pkg-install ${PKGNAME} POST-INSTALL として実行されます. どちらのモードで実行されているかは $2 を調べることによってわかります. 環境変数 PKG_PREFIX には package がインストールされるディレクトリが設定されます. 詳細は pkg_add(1) を見てください.
Note: port を make install でインストールするときにはこのスクリプトは自動的に実行されません. もし実行される必要があるならば port の Makefile から明示的に呼ぶ必要があります.
(訳注: 実行されるマシンの状態に応じて) その port を インストールするべきか, そうでないかを判断する必要があるときには, ``要件 (requirements)'' スクリプト pkg-req を作ることができます. インストールや削除を実行すべきかどうか判断するために, このスクリプトがインストールや削除を実行する際に自動的に 実行されます.
このスクリプトはインストール時には pkg_add により pkg-req ${PKGNAME} INSTALL として実行され, 削除時には pkg_delete により pkg-req ${PKGNAME} DEINSTALL として 実行されます.
いくつかの port, 特に p5-ports などは configure のオプション (あるいは, p5-ports の場合は perl のバージョン) によって pkg-plist を変える必要があります. これを容易に実現するために pkg-plist 中の %%OSREL%%, %%PERL_VER%%, %%PERL_VERSION%% は適切に置き換えられるようになっています. %%OSREL%% の値はオペレーティングシステムの数字で表されたリビジョンです (たとえば 2.2.7). %%PERL_VERSION%% は perl のバージョン番号全体 (たとえば 5.00502) で, %%PERL_VER%% はバージョン番号からパッチレベルを引いたものです (たとえば 5.005).
他の置き換えが必要であれば, PLIST_SUB 変数に VAR=VALUE という形式のペアのリストを設定することによって, pkg-plist 中の %%VAR%% は VALUE に置き換えられます. たとえばバージョンに固有のたくさんのファイルをインストールする場合には, Makefile に
OCTAVE_VERSION= 2.0.13
PLIST_SUB= OCTAVE_VERSION=${OCTAVE_VERSION}
と書いて, PLIST 中のバージョン番号が表われるすべてのところに, %%OCTAVE_VERSION%% と書きます. このようにしておけば, port をアップグレードするときに, 何十行 (時として, 何百行) も pkg-plist を書き替えないですみます.
この書き換えは (マニュアルの追加も) do-install と post-install ターゲットの間に pkg-plist を読み TMPPLIST (デフォルトは WRKDIR/.PLIST.mktmp) に書き込むことによって行なわれます. もし, あなたの port が PLIST を実行時に生成するのであれば, do-install の間かその前に行なうようにしてください. また, 書きかえられたあとのファイルを編集する必要がある場合には, post-install で TMPPLIST を書きかえてください.
pkg-*ファイルの 名前はすべて変数を使用して定義されていますので, 必要であれば Makefile 中で変更可能です. いくつかの ports で一つの pkg-* ファイルを共有する場合や, 上記のファイルに書き込みをしなければならないときなど特に便利です (pkg-* サブディレクトリに直接書き込むのが良くない理由については WRKDIR 以外への書きこみ を参照してください).
以下に変数名と そのデフォルト値のリストを示します. (PKGDIR のデフォルト値は ${MASTERDIR} になっています.)
| 変数名 | デフォルト値 |
|---|---|
| COMMENT | ${PKGDIR}/pkg-comment |
| DESCR | ${PKGDIR}/pkg-descr |
| PLIST | ${PKGDIR}/pkg-plist |
| PKGINSTALL | ${PKGDIR}/pkg-install |
| PKGDEINSTALL | ${PKGDIR}/pkg-deinstall |
| PKGREQ | ${PKGDIR}/pkg-req |
| PKGMESSAGE | ${PKGDIR}/pkg-message |
PKG_ARGS を上書きせずにこれらの変数を変更するようにしてください. PKG_ARGS を変更すると, これらのファイルは port から正しく /var/db/pkg にインストールされなくなります.
ソフトウェアによっては, 制約の厳しいライセンス条件が 定められている場合もありますし, 国によっては (特許権の侵害などで) 法律的に問題がある可能性もあります. それらをどう扱えばいいかは, それぞれのライセンスの文面によって 大きく異なります.
Note: ソフトウェア移植者として, あなたにはライセンスをよく読み FreeBSD プロジェクトが FTP または CD-ROM で配布してはいけないソフトウェアを配布してしまうことのないよう注意する義務があります. 何か疑問がある場合には FreeBSD ports メーリングリスト に聞いてみてください.
よく見られるケースに対処するために, Makefile に指定できる二つの変数が用意されています.
ソフトウェアに``有償再配布を禁ずる''という趣旨のライセン スがついてきた場合には, NO_CDROM という変数にその理由を記述してください. わたしたちはこれがついている port を CDROM リリースに入れないようにしますが, オリジナルのソースファイルと package を FTP で取れるようにしておきます.
もし生成される package が個々のサイトで独自に構築される必要があったり, ライセンスによって生成されるバイナリが配布できない場合には NO_PACKAGE 変数にその理由を記述してください. そのような package は FTP サイトに置かれたり, リリース 時の CDROM へ入らないようにします. ただし, いずれの場合も 配布ファイルは (FTP や CD-ROM に) 含まれるようになります.
(特許などの関係で) 使用者によっては法律上の問題が生じたり, ``商用利用を禁ずる''ライセンスを持つ port の場合には, その理由を RESTRICTED という変数に入れてください. このような port の場合には, 配布ファイルや package も FreeBSD の FTP サイトに置かれないようになります.
Note: GNU 一般公有使用許諾書 (GPL) は, バージョン 1, 2 とも port 作成上何ら問題にはなりません.
Note: もしあなたがソースツリー管理者 (committer) であれば, ソースツリーにこのような port を入れる際に ports/LEGAL ファイルを書き換えるのを忘れないようにしてください.
port のバージョンが原作者からのものに比べて古いことに気がついたら, まずはあなたの持っている port が私たちの最新のもの (FTP ミラーサイトの ports/ports-current というディレクトリにあります) であることを確認してください. また, Ports Collection 全体を最新の状態に保つために CVSup を利用することもできます. 詳しくは FreeBSD ハンドブックをご覧ください.
次に port の Makefile に MAINTAINER (保守担当者) のアドレスが書いてある場合には, その人にメールを出してみましょう. 保守担当者の人がすでにアップグレードの準備をしているかも知れませんし, (新しいバージョンの安定度に問題があるなど) あえてアップグレードをしない理由があるのかも知れません.
保守担当者にアップグレードをしてくれと頼まれた場合, あるいは, そもそも port の Makefile に保守担当者が書いてない場合などは, あなたがアップグレードをしてくださると助かります. その場合にはアッ プグレードをした後, 変更前と変更後のディレクトリの再帰的 diff (unified diff と context diff のどちらでもいいのですが, port のコミッター達は unified diff の方を好むようです) をとって送ってください (たとえば変更前のディレクトリが superedit.bak という名前でとってあり, 変更後のものが superedit に入っているなら, diff -ruN superedit.bak superedit の結果を送ってください). diff の出力を見て, すべての変更が正しくなされているか確認してください. 変更箇所については, send-pr(1) (カテゴリは ports) に diff の出力結果を添えて, わたしたちに送ってもらうのが一番良いです. commit する際に CVS に明確に記述しなければならないので, 付け加えたり削除したりしたファイルがあればそれについて書いておいてください. もし diff の大きさが 20 KB 程度を超えるようであれば, 圧縮したものを uuencode してください. そうでなければそのまま PR に入れるだけで構いません.
Note: 繰り返しになりますが, 既存の ports の変更を送るときには shar(1) ではなく diff(1) を使用してください!
このセクションではソフトウェアを port する上で, 良くある落し穴などについて説明します. このリストを使ってあなた自身が作成した port のチェックはもとより, PR データベースにある, 他の人が作成した port のチェックもできます. あなたがチェックした port についてのコメントをバグ報告と一般的な論評にしたがって送ってください. PR データベースにある port をチェックすると, わたしたちがそれらを commit するのを早くし, あなたが何をしているか理解していることも示します.
バイナリは strip してください. オリジナルのソースがバイナリを strip してくれる場合は良いですが, そうでない場合には port の Makefile が install ターゲットを持っているなら BSD_INSTALL_PROGRAM を, 持っていないなら strip するための post-install ルールを追加して strip するようにするとよいでしょう. たとえばこんな風になります:
post-install:
strip ${PREFIX}/bin/xdl
インストールされた実行形式がすでに strip されているかどうかは file コマンドで確認できます. ``not stripped'' と表示されなければ strip されていることを示しています.
あなた自身の *-install ターゲットでファイルの正しいモードとオーナを保証するために, 必ず bsd.port.mk で提供されているマクロを使用してください.
${INSTALL_PROGRAM} は実行可能なバイナリをインストール (し, その過程で strip 処理)するコマンドです.
${INSTALL_SCRIPT} は実行可能なスクリプトをインストールするコマンドです.
${INSTALL_DATA} は共有可能なデータをインストールするコマンドです.
${INSTALL_MAN} はマニュアルとその他の文書をインストールするコマンドです (圧縮はしません).
これらは基本的に install コマンドに適切なフラグを与えたものです. それらは distfile の Makefile で, 頭に ``BSD_'' が付けられた (つまり BSD_INSTALL_PROGRM というような) 形で使うことができます. どのようにこれらを使用するかは以下の例を見てください.
WRKDIR の外に存在するファイルには 何も書き込んではいけません. port のビルド中に書き込み可能なことが保証されているのは WRKDIR の中だけです (書き込み不可のツリー上での port ビルドの例については, CDROM からの ports のコンパイル を参照のこと). pkg-* ファイルを 変更する必要があるときには, ファイルを上書きするのではなく 変数の再定義により 行なうようにしてください.
WRKDIRPREFIX を尊重していることを確認してください. 特に, 別の port の WRKDIR を参照しているときには気を付けてください. 正しい場所は, WRKDIRPREFIXPORTSDIR/subdir/name/work です, PORTSDIR/subdir/name/work や .CURDIR/../../subdir/name/work ではありません.
また, 自分で WRKDIR 定義するときには先頭に ${WRKDIRPREFIX}${.CURDIR} が付いていることを確認してください.
どのバージョンの Unix で動かすかによって, 変更や 条件つきコンパイルが必要なコードに出くわすこともあるでしょう. そのような変更を行なう場合には, FreeBSD 1.x システムへのバックポートや, CSRG の 4.4BSD, BSD/386, 386BSD, NetBSD, OpenBSD 等, 他の BSD システムへの移植が可能なように, できるだけ汎用的な変更を行なうことを心がけてください.
4.3BSD/Reno (1990) と, それより新しいバージョンの BSD コードを 区別するには, <sys/param.h> で定義されている BSD マクロを利用するのがよいでしょう. このファイルがすでにインクルードされていれば良いのですが, そうでない場合には, その .c ファイルの 適当な場所に以下のコードを追加してください.
#if (defined(__unix__) || defined(unix)) && !defined(USG) #include <sys/param.h> #endif
これらの二つのシンボルが定義されているシステムには必ず sys/param.h があるはずです. もしそうでないシステムを発見したら, FreeBSD ports メーリングリスト までメールを送ってわたしたちに伝えてください.
あるいは, GNU Autoconf のスタイルを使用することもできます,
#ifdef HAVE_SYS_PARAM_H #include <sys/param.h> #endif
この方法を使用するときには, Makefile 中の CFLAGSに -DHAVE_SYS_PARAM_H を加えることを忘れないようにしてください.
いったん sys/param.h がインクルードされると,
#if (defined(BSD) && (BSD >= 199103))
このようにしてそのコードが 4.3 Net2 コードベース, またはそれより新しいもの (例: FreeBSD 1.x, 4.3/Reno, NetBSD 0.9, 386BSD, BSD/386 1.1 とそれ以前) の上でコンパイルされているかを検出できます.
#if (defined(BSD) && (BSD >= 199306))
これは, 4.4コードベース, またはそれより新しいもの (例: FreeBSD 2.x, 4.4, NetBSD 1.0, BSD/386 2.0 とそれ以後) の上でコンパイルされているかどうかを検出するために使用します.
4.4BSD-Lite2 コードベースでは BSD マクロの値は 199506 になっています. これは参考程度の意味合いしかありません. 4.4-Lite ベースの FreeBSD と 4.4-Lite2 での変更がマージされたバージョンとを区別するのに使用するべきものではありません. この目的のためにはかわりに __FreeBSD__ マクロを使用してください.
以下は控え目に使ってください.
__FreeBSD__ はFreeBSDのすべての版で定義されています. 変更が
FreeBSD だけに適用されるとき以外は使用しないでください. port でよくある strerror() ではなく sys_errlist[]
を使うなどは FreeBSDでの変更ではなく BSD の流儀です.
FreeBSD 2.xでは __FreeBSD__ が 2 と定義されています. それ以前の版では 1 になっています. その後の版ではそのメジャー番号に合うように上がっていきます.
もし FreeBSD 1.x システムと FreeBSD 2.x, あるいは FreeBSD 3.x システムを区別する必要があれば, 上で述べた BSD マクロを使用するのが大抵の場合において正しい答です. もし FreeBSD 特有の変更であれば (ld を使うときの共有ライブラリ用のオプションなど), __FreeBSD__を使い #if __FreeBSD__ > 1 のようにFreeBSD 2.x および, それ以降のシステムを検出するのはかまいません. もし 2.0-RELEASE 以降の FreeBSD システムを細かく検出したければ, 以下を使用することができます.
#if __FreeBSD__ >= 2
#include <osreldate.h>
# if __FreeBSD_version >= 199504
/* 2.0.5+ release specific code here */
# endif
#endif
| Release | __FreeBSD_version |
|---|---|
| 2.0-RELEASE | 119411 |
| 2.1-CURRENT | 199501, 199503 |
| 2.0.5-RELEASE | 199504 |
| 2.1 以前の 2.2-CURRENT | 199508 |
| 2.1.0-RELEASE | 199511 |
| 2.1.5 以前の 2.2-CURRENT | 199512 |
| 2.1.5-RELEASE | 199607 |
| 2.1.6 以前の 2.2-CURRENT | 199608 |
| 2.1.6-RELEASE | 199612 |
| 2.1.7-RELEASE | 199612 |
| 2.2-RELEASE | 220000 |
| 2.2.1-RELEASE | 220000 (変更なし) |
| 2.2.1-RELEASE 以降の 2.2-STABLE | 220000 (変更なし) |
| texinfo-3.9 以降の 2.2-STABLE | 221001 |
| top 導入以降の 2.2-STABLE | 221002 |
| 2.2.2-RELEASE | 222000 |
| 2.2.2-RELEASE 以降の 2.2-STABLE | 222001 |
| 2.2.5-RELEASE | 225000 |
| 2.2.5-RELEASE 以降の 2.2-STABLE | 225001 |
| ldconfig -R マージ以降の 2.2-STABLE | 225002 |
| 2.2.6-RELEASE | 226000 |
| 2.2.7-RELEASE | 227000 |
| 2.2.7-RELEASE 以降の 2.2-STABLE | 227001 |
| semctl(2) 変更以降の 2.2-STABLE | 227002 |
| 2.2.8-RELEASE | 228000 |
| 2.2.8-RELEASE 以降の 2.2-STABLE | 228001 |
| mount(2) 変更以前の 3.0-CURRENT | 300000 |
| mount(2) 変更以降の 3.0-CURRENT | 300001 |
| semctl(2) 変更以降の 3.0-CURRENT | 300002 |
| ioctl 引数変更以降の 3.0-CURRENT | 300003 |
| ELF 化以降の 3.0-CURRENT | 300004 |
| 3.0-RELEASE | 300005 |
| 3.0-RELEASE 以降の 3.0-CURRENT | 300006 |
| 3/4 の分岐以降の 3.0-STABLE | 300007 |
| 3.1-RELEASE | 310000 |
| 3.1-RELEASE 以降の 3.1-STABLE | 310001 |
| C++ コンストラクタ/デストラクタ順序変更の後の 3.1-STABLE | 310002 |
| 3.2-RELEASE | 320000 |
| 3.2-STABLE | 320001 |
| バイナリ互換性のない IPFW とソケットの変更後の 3.2-STABLE | 320002 |
| 3.3-RELEASE | 330000 |
| 3.3-STABLE | 330001 |
| libc に mkstemp(3) が追加された後の 3.3-STABLE | 330002 |
| 3.4-RELEASE | 340000 |
| 3.4-STABLE | 340001 |
| 3.4 が分岐した後の 4.0-CURRENT | 400000 |
| dynamic linker の変更後の 4.0-CURRENT | 400001 |
| C++ コンストラクタ/デストラクタ順序変更の後の 4.0-CURRENT | 400002 |
| dladdr(3) 機能追加後の 4.0-CURRENT | 400003 |
| __deregister_frame_info dynamic linker のバグ修正, EGCS 1.1.2 導入後の 4.0-CURRENT | 400004 |
| suser(9) の API 変更, newbus 化 以降の 4.0-CURRENT | 400005 |
| cdevsw 登録方法の変更後の 4.0-CURRENT | 400006 |
| ソケットレベルの証明書 (credential) のために so_cred が追加された後の 4.0-CURRENT | 400007 |
| libc_r への poll syscall ラッパー追加後の 4.0-CURRENT | 400008 |
| kernel の dev_t 型から struct spacinfo ポインタへの 変更後の 4.0-CURRENT | 400009 |
| jail(2) のセキュリティホール 修正後の 4.0-CURRENT | 400010 |
| sigset_t の データ型変更後の 4.0-CURRENT | 400011 |
| システムコンパイラを gcc 2.95.2 にアップグレードした 後の 4.0-CURRENT | 400012 |
| 動的組み込み可能な Linux モードの ioctl ハンドラが 追加された後の 4.0-CURRENT | 400013 |
| OpenSSL 導入後の 4.0-CURRENT | 400014 |
| GCC 2.95.2 の C++ ABI 変更で, デフォルトを -fvtable-thunks から -fno-vtable-thunks に 変更した後の 4.0-CURRENT | 400015 |
| OpenSSH 導入後の 4.0-CURRENT | 400016 |
| 4.0-RELEASE | 400017 |
| 4.0-RELEASE 以降の 4.0-STABLE | 400018 |
| libxpg4 が libc にマージされた後の 4.0-STABLE | 400020 |
| Binutils を 2.10.0 にアップグレードし, ELF バイナリのマーク付け (branding) 方法を変更し, tcsh をベースシステムに導入した後の 4.0-STABLE | 400021 |
| 4.1-RELEASE | 410000 |
| 4.1-RELEASE 以降の 4.1-STABLE | 410001 |
| setproctitle(3) が libutil から libc に 移動した後の 4.1-STABLE | 410002 |
| 4.1.1-RELEASE | 411000 |
| 4.1.1-RELEASE 以降の 4.1.1-STABLE | 411001 |
| 4.2-RELEASE | 420000 |
| libgcc.a と libgcc_r.a の結合および, 関連する GCC linkage 変更が行なわれた後の 4.2-STABLE | 420001 |
| 4.3-RELEASE | 430000 |
| wint_t 導入後の 4.3-STABLE | 430001 |
| PCI パワーステート API マージ後の 4.3-STABLE | 430002 |
| 5.0-CURRENT | 500000 |
| ELF ヘッダフィールドの追加と ELF バイナリのマーク付け (branding) 方法の変更後の 5.0-CURRENT | 500001 |
| kld メタデータ変更後の 5.0-CURRENT | 500002 |
| buf/bio 変更後の 5.0-CURRENT | 500003 |
| binutils アップグレード後の 5.0-CURRENT | 500004 |
| libxpg4 コードの libc へのマージと, TASKQ インターフェイスの導入後の 5.0-CURRENT | 500005 |
| AGP インターフェイス追加後の 5.0-CURRENT | 500006 |
| Perl を 5.6.0 にアップグレードした後の 5.0-CURRENT | 500007 |
| KAME コードを 2000/07 版のソースに更新した後の 5.0-CURRENT | 500008 |
| ether_ifattach() および ether_ifdetach() 変更後の 5.0-CURRENT | 500009 |
| mtree のデフォルトをオリジナルの変種に戻し, シンボリックリンクをたどる -L オプションを追加した後の 5.0-CURRENT | 500010 |
| kqueue API 変更後の 5.0-CURRENT | 500011 |
| setproctitle(3) が libutil から libc へ移動した後の 5.0-CURRENT | 500012 |
| 最初の SMPng がコミットされた後の 5.0-CURRENT | 500013 |
| <sys/select.h> が <sys/selinfo.h> に 移動した後の 5.0-CURRENT | 500014 |
| libgcc.a と libgcc_r.a の結合および関連する GCC linkage 変更が行なわれた後の 5.0-CURRENT | 500015 |
| libc と libc_r の混合リンクを許し, -pthread オプションを deprecate する 変更後の 5.0-CURRENT | 500016 |
| mountd 等が使用する kernel-exported API の 安定化のため, ucred 構造体から xucred 構造体へ 移行した後の 5.0-CURRENT | 500017 |
| CPU 依存の最適化を制御するための make 変数 CPUTYPE が追加された後の 5.0-CURRENT | 500018 |
| <machine/ioctl_fd.h> が <sys/fdcio.h> に移動した後の 5.0-CURRENT | 500019 |
| ロケール名変更の後の 5.0-CURRENT | 500020 |
| Bzip2 導入後の 5.0-CURRENT | 500021 |
| SSE サポート後の 5.0-CURRENT | 500022 |
Note: (2.2-STABLE は 2.2.5-RELESE 以後, ``2.2.5-STABLE'' と呼ばれることがあります.) 見てのとおりこれは年・月というフォーマットになっていましたが, バージョン 2.2 からより直接的にメジャー/マイナー番号を使うように変更になりました. 並行していくつかのブランチ (枝分かれしたバージョン) を開発する場合には, リリースされた日付でそれらのリリースを分類することが不可能だからです (あなたが今 port を作成するときに, 古い -CURRENT 達について心配する必要はありません. これは参考のために挙げられているに過ぎないからです).
これまで, 何百もの port が作られてきましたが, __FreeBSD__ が正しく使われたのは一つか二つの場合だけでしょう. 以前の port が誤った場所でそのマクロを使っているからといって, それをまねする理由はありません.
.include <bsd.port.mk> の行の後には何も書かないようにしてください. 大抵の場合は Makefile の中程のどこかで bsd.port.pre.mk をインクルードして, 最後に bsd.port.pre.mk をインクルードすることによって避けることができます.
Note: pre.mk/post.mk のペアか bsd.port.mk だけのどちらかだけをインクルードし, 二つを混ぜないでください.
前者はいくつかの変数の定義だけをして Makefile でのテストに使用し, 後者は残りを定義します.
以下は bsd.port.pre.mk で定義される重要な変数です (これは, すべてではありません. 完全なリストは bsd.port.mk を参照してください).
| 変数名 | 解説 |
|---|---|
| ARCH | uname -m で返される アーキテクチャ. (例, i386). |
| OPSYS | uname -s で返される オペレーティングシステム (例, FreeBSD). |
| OSREL | オペレーティングシステムの リリースバージョン (例., 2.1.5, 2.2.7). |
| OSVERSION | 数字形式のオペレーティングシステム のバージョン, 上記の __FreeBSD_version と同じです. |
| PORTOBJFORMAT | システムのオブジェクト フォーマット (aout あるいは elf). |
| LOCALBASE | ``local'' ツリーのベース. (例, /usr/local/). |
| X11BASE | ``X11'' ツリーのベース. (例, /usr/X11R6/). |
| PREFIX | ports のインストール先 ( PREFIXについてを参照). |
Note: USE_IMAKE, USE_X_PREFIX あるいは MASTERDIR などの変数を定義する必要がある場合には, bsd.port.pre.mk をインクルード前に定義してください. 他のものは bsd.port.pre.mk の前でも後でもかまいません.
以下は bsd.port.pre.mk の後に書けるものの例です.
# no need to compile lang/perl5 if perl5 is already in system
.if ${OSVERSION} > 300003
BROKEN= perl is in system
.endif
# only one shlib version number for ELF
.if ${PORTOBJFORMAT} == "elf"
TCL_LIB_FILE= ${TCL_LIB}.${SHLIB_MAJOR}
.else
TCL_LIB_FILE= ${TCL_LIB}.${SHLIB_MAJOR}.${SHLIB_MINOR}
.endif
# software already makes link for ELF, but not for a.out
post-install:
.if ${PORTOBJFORMAT} == "aout"
${LN} -sf liblinpack.so.1.0 ${PREFIX}/lib/liblinpack.so
.endif
普通のマニュアルや info ファイルの他にユーザにとって有用だと思えるような文書がある場合には, PREFIX/share/doc の下にインストールしてください. これは前記と同様 post-install ターゲットの中から行なうと良いでしょう.
まず, あなたの port のために新しいディレクトリを作ります. どの port の文書か簡単にわかるような名前にする必要がありますので, 普通は PORTNAME を使うと良いでしょう. もちろん, ユーザが異なるバージョンのものを同時に使うことが予想される port の場合には PKGNAME をそのまま使っても構いません.
ユーザが /etc/make.conf でこの部分を禁止するために NOPORTDOCS という変数をセットしている場合には, これらの文書がインストールされないようにしてください. こんな具合です.
post-install:
.if !defined(NOPORTDOCS)
${MKDIR} ${PREFIX}/share/doc/xv
${INSTALL_MAN} ${WRKSRC}/docs/xvdocs.ps ${PREFIX}/share/doc/xv
.endif
文書ファイルおよびディレクトリはすべて pkg-plist の中に %%PORTDOCS%% を頭につけて書く必要があります. たとえば, 次のようにしてください.
%%PORTDOCS%%share/doc/pure-ftpd/AUTHORS %%PORTDOCS%%share/doc/pure-ftpd/CONTACT %%PORTDOCS%%@dirrm share/doc/pure-ftpd
インストール時に pkg-message ファイルを利用してメッセージを表示することができます. 詳細は pkg-message を使うのセクションを 参照してください.
Note: pkg-message ファイルを pkg-plist に加える必要はありません.
/usr/ports/distfiles ディレクトリ内をあまり散らかさないようにしてください. たくさんのファイルを取ってくる port や, 数は少なくても他の port のファイルと混同される恐れがあるファイル (Makefile など) がある場合には, DIST_SUBDIR に port の名前 (${PORTNAME} か ${PKGNAMEPREFIX}${PORTNAME} を使うといいでしょう) を入れてください. すると DISTDIR がデフォルトの /usr/ports/distfiles から /usr/ports/distfiles/DIST_SUBDIR に変更され, 取ってきたファイルはすべてそのサブディレクトリの中に置かれるようになります.
また, ファイルを取ってくるときにバックアップサイトとして使われる ftp.FreeBSD.org のディレクトリ名にもこの変数の値が使わ�