diff options
Diffstat (limited to 'share/doc/ja_JP.EUC/handbook/porting.sgml')
| -rw-r--r-- | share/doc/ja_JP.EUC/handbook/porting.sgml | 1416 |
1 files changed, 0 insertions, 1416 deletions
diff --git a/share/doc/ja_JP.EUC/handbook/porting.sgml b/share/doc/ja_JP.EUC/handbook/porting.sgml deleted file mode 100644 index 32ea4d3..0000000 --- a/share/doc/ja_JP.EUC/handbook/porting.sgml +++ /dev/null @@ -1,1416 +0,0 @@ -<!-- $Id: porting.sgml,v 1.20 1997/05/18 12:16:02 max Exp $ --> -<!-- The FreeBSD Japanese Documentation Project --> -<!-- Original revision: 1.70 --> - -<sect1><heading>フリーソフトウェアの移植<label id="porting"></heading> - -<p><em>原作: &a.jkh;, &a.gpalmer; &a.asami;. -<newline>7 November 1996.</em> - -<p><em>訳: &a.simokawa;, &a.asami;. -<newline>10 November 1996.</em> - -<p>フリーで手に入るソフトウェアを移植することは, 何かをゼロから自分で -作ることほどは人に感謝されないにしても, どこに手を入れれば動くのかわから -ないような人でも使えるようにするという意味で, FreeBSDの発展のためにとて -も重要なことです. 移植されたすべてのソフトウェアは「Portsコレク -ション」(the Ports Collection) と呼ばれ, 階層的に分類されて集められ -ています. これによって, 新しいユーザでも, 何がすぐに簡単にコンパイルで -きる状態で手に入るのか, についての概要をつかむことができます. また, 移植されるソー -スコードについては, そのほとんどを実際には含まず, FreeBSDで動かすためのほんのちょっ -との差分ファイルといくつかの定義ファイルだけをソースツリーに入れることで, -かなりのディスクスペースが節約できます. - -<p>これから, FreeBSD 2.x用のportを作る際の, いくつかのガイドラインを -説明します. 実際にportをコンパイルするときのほとんどの仕事は -<tt>/usr/share/mk/bsd.port.mk</tt>というファイルでおこないます. -Portsコレクションについてのさらに細かい内部の働きについては, そちらのファイルを -参照してください. - - <sect2> - <heading>移植を始める前に<label id="porting:starting"></heading> - - <p>注意: ここでは, 変更可能な変数の一部についてのみ記述してい - ます. ほとんどの変数は<tt>bsd.port.mk</tt>の始めに記述があり - ます. また, このファイルは非標準のタブの設定になっていま - す. <tt>Emacs</tt>はファイルのロード時にこれを認識しますが, - <tt>vi</tt>や<tt>ex</tt>では, ファイルをロードしたら - `<tt>:set tabstop=4</tt>'のようにして正しい値を設定することがで - きます. - - <p>Portの過程で, 修正や, どのバージョンのUNIXで動くかによる条件 - つきコンパイルなどが必要なコードに出会うかもしれません. その - ような条件つきコンパイルなどのための変更をおこなうときには, - FreeBSD 1.x システムへの移植や, CSRGの4.4BSD, BSD/386, - 386BSD, NetBSDなどの他のBSDシステムへの移植が可能なように, でき - るだけ普遍的な変更をおこなうことを心がけてください. - - <p>4.3BSD/Renoおよびそれより新しいBSD版を古いバージョンと区別す - るには `<tt>BSD</tt>' マクロを利用するのがよいでしょう. これは - <tt><sys/param.h></tt>で定義されています. このファイルが - すでにインクルードされていればよいのですが, もしそうでない場合 - には以下のコードを, その<tt>.c</tt> ファイルの適当な場所に加 - えてください. - -<tscreen><verb> -#ifdef (defined(__unix__) || defined(unix)) && !defined(USG) -#include <sys/param.h> -#endif -</verb></tscreen> - - <p>これらのシンボルが定義されているすべてのシステムには - sys/param.h があるはずです. もし, そうでないシステムを発見した - ら我々にも教えてください. - <htmlurl url='mailto:ports@FreeBSD.org' name='ports@FreeBSD.org'> - までメールを送ってください. - - <p>あるいは, GNU の Autoconf のスタイルを使用することもできます, - -<tscreen><verb> -#ifdef HAVE_SYS_PARAM_H -#include <sys/param.h> -#endif -</verb></tscreen> - - この方法を使用するときには, Makefile 中の<tt>CFLAGS</tt>に - <tt>-DHAVE_SYS_PARAM_H</tt> を加えることを忘れないようにしてく - ださい. - - いったん<tt><sys/param.h></tt>がインクルードされると, - -<tscreen><verb> -#if (defined(BSD) && (BSD >= 199103)) -</verb></tscreen> - - このようにしてそのコードが4.3 Net2コードベース, または - それより新しいもの (例: FreeBSD 1.x, 4.3/Reno, NetBSD 0.9, 386BSD, - BSD/386 1.1とそれ以前) の上でコンパイルされているかを検出できます. - -<tscreen><verb> -#if (defined(BSD) && (BSD >= 199306)) -</verb></tscreen> - - これは, 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__ マクロをかわりに使用してくださ - い. - - <p>以下は控え目に使ってください. - - <itemize> - <item><tt>__FreeBSD__</tt> はFreeBSDのすべての版で定義されてい - ます. 変更がFreeBSDだけに適用されるとき以外は使用しないでく - ださい. Portでよくある, <tt>strerror()</tt> ではなく - <tt>sys_errlist[]</tt> を使うなどは, FreeBSDでの変更ではなく, - BSDの流儀です. - - <item>FreeBSD 2.xでは<tt>__FreeBSD__</tt>が2と定義されていま - す. それ以前の版では1になっています. - - <item>もし, FreeBSD 1.xシステムとFreeBSD 2.xシステムを区別 - する必要があれば, 上で述べた<tt>BSD</tt>マクロを使用するのが, - 大抵の場合において正しい答です. もし, FreeBSD特有の変更であ - れば (`<tt>ld</tt>' を使うときのシェアードライブラリ用のな - オプションなど), <tt>__FreeBSD__</tt>を使い - `<tt>#if __FreeBSD__ > 1</tt>' のようにFreeBSD 2.x - システムを検出するのはかまいません. - - もし, 2.0-RELEASE以降のFreeBSDシステムを細かく検出したけれ - ば, 以下を使用することができます. - -<tscreen><verb> -#if __FreeBSD__ >= 2 -#include <osreldate.h> -# if __FreeBSD_version >= 199504 - /* 2.0.5+ release specific code here */ -# endif -#endif -</verb></tscreen> -<tt>__FreeBSD_version</tt> の値は以下の通りです: -<tscreen><verb> -2.0-RELEASE: 199411 -2.1-current's: 199501, 199503 -2.0.5-RELEASE: 199504 -2.2-current (2.1以前): 199508 -2.1.0-RELEASE: 199511 -2.2-current (2.1.5以前): 199512 -2.1.5-RELEASE: 199607 -2.2-current (2.1.6以前): 199608 -2.1.6-RELEASE: 199612 -2.1.7-RELEASE: 199612 -2.2-RELEASE: 220000 -2.2.1-RELEASE: 220000 (2.2-RELEASE と同じです) -2.2-STABLE (2.2.1-RELEASE 以後): 220000 (これも同じです) -2.2-STABLE (texinfo-3.9 以後): 221001 -2.2-STABLE (top 導入以後): 221002 -2.2-RELEASE: 222000 -3.0-current (1997年5月現在): 300000 -</verb></tscreen> - 見ての通り, これは年・月というフォーマットになっていましたが, - バージョン 2.2 から, より直接的にメジャー/マイナー番号を使う - ように変更になりました. 並行していくつかのブランチ(枝分かれし - たバージョン)を開発する場合には, リーリスされた日付でそれらの - リリースを分類することが不可能だからです. - (あなたが今 port を作成するときに, 古い -current 達について心配 - する必要はありません. これは参考のために挙げられているにすぎま - せん.) - - </itemize> - - <p>これまで, 何百ものportが作られてきましたが, - <tt>__FreeBSD__</tt>が正しく使われたのは, 1つか2つの場合だけで - しょう. 以前のportが誤った場所でそのマクロが使っているからと - いって, それをまねする理由はありません. - - <sect2> - <heading>3分porting</heading> - - <p>この節では, 簡単なportの方法について説明します. 多くの場合これ - では不十分ですが, まあうまくいくかどうか試してみて損はないでしょ - う. - - <p>まず, 元のtarファイルを<tt>${DISTDIR}</tt>に置きます. - デフォルトは<tt>/usr/ports/distfiles</tt>です. - - <p>注: 以下では, ソフトウェアはそのままコンパイルされるとします. - つまり, FreeBSDのマシンで動かすために, 変更がまったく必要ない - とします. もしなにか変更が必要な場合には次の節も参照する必要 - があります. - - <sect3> - <heading>Makefileの作成</heading> - - <p>最小限の<tt>Makefile</tt>は次のようなものです: - -<tscreen><verb> - # New ports collection makefile for: oneko - # Version required: 1.1b - # Date created: 5 December 1994 - # Whom: asami - # - # $Id$ - # - - DISTNAME= oneko-1.1b - CATEGORIES= games - MASTER_SITES= ftp://ftp.cs.columbia.edu/archives/X11R5/contrib/ - - MAINTAINER= asami@FreeBSD.ORG - - USE_IMAKE= yes - - .include <bsd.port.mk> -</verb></tscreen> - - <p>おわかりになりますでしょうか. <tt>$Id$</tt>があ - る行の内容については, 気にしないでください. これはこのファイル - がportsツリーに書き込まれるときにCVSによって自動的に書 - き込まれます. もっと詳しい例が見たければ, <ref - id="porting:samplem" name="Makefileのお手本">の節をご覧ください. - - <sect3> - <heading>Package記述ファイルの作成</heading> - - <p>どのようなportでも, packageにするしないに関わらず, 3つ - の記述ファイルが必要です. <tt>pkg</tt>サブディレクトリにある, - <tt>COMMENT</tt>, <tt>DESCR</tt>, それに<tt>PLIST</tt>です. - - <sect4> - <heading>COMMENT</heading> - - <p>これには, そのportについての説明を1行で書きます. Package - の名前, バージョン番号等は<em>含めない</em>でください. - たとえば, こんな具合です: - -<tscreen><verb> -A cat chasing a mouse all over the screen -</verb></tscreen> - - <sect4> - <heading>DESCR</heading> - - <p>これは, そのソフトウェアについての, すこし長い説明を記述しま - す. そのportが何をするのかについての数段落程度の簡潔な解説があれば - 十分です. 注: このファイルはマニュアルでもなければ, 使用方 - 法やコンパイル方法についての細かい説明書ではありません. 特 - に, <tt>README</tt>ファイルを何も考えずにここにコピーするような - ことはしないでください. (もちろん, READMEがそのソフトウ - ェアの簡潔な説明になっている場合は別ですが.) - - <p>このファイルの最後にあなたの名前を書くことが推奨されています. - たとえば, こんな具合です. - -<tscreen><verb> -This is a port of oneko, in which a cat chases a poor mouse all over -the screen. - : -(うんぬん.) - -- Satoshi -asami@cs.berkeley.edu -</verb></tscreen> - - <sect4> - <heading>PLIST</heading> - - <p>このファイルには, このportによってインストールされるファ - イルが列挙されます. このファイルはpackageを作る際のリス - トとして使われるため, `packing list' とも呼ばれます. ここ - に書かれているファイル名は, インストール時のプレフィックス - (普通は<tt>/usr/local</tt>か<tt>/usr/X11R6</tt>) からの - 相対パスです. - - <p>簡単な例を載せておきましょう: - -<tscreen><verb> -bin/oneko -man/man1/oneko.1.gz -lib/X11/app-defaults/Oneko -lib/X11/oneko/cat1.xpm -lib/X11/oneko/cat2.xpm -lib/X11/oneko/mouse.xpm -</verb></tscreen> - - <p> 'Packing list'の詳細については, <tt>pkg_create(1)</tt>の - マニュアルを参照してください. - - <sect3> - <heading>チェックサムファイルの作成</heading> - - <p>ただ, `<tt>make makesum</tt>' と入力するだけです. - bsd.port.mkにルールがあるので, 自動的に<tt>files/md5</tt>が - 生成されます. - - <sect3> - <heading>Portのテスト</heading> - - <p>そのportが正しく動くことを, package化を含めて確認してく - ださい. まず, `<tt>make install</tt>', `<tt>make - package</tt>' を試してください. また, `<tt>pkg_delete -d - <pkgname></tt>' をして,すべてのファイルが正しく消去さ - れているかどうかを確認してください. それから, `<tt>pkg_add - <pkgname>.tgz</tt>' をおこない, すべてのファイルが再び現 - れ, 正しく動作することを確認してください. - - <sect3> - <heading>Portの送付<label id="porting:submitting"></heading> - - <p>さあ, あなたのportに満足したら, あとはそれをFreeBSDのメイ - ンのportsツリーに置いて, 皆に使ってもらうだけです. そのた - めには, 必要なファイル (この節で述べたすべてのファイル -- た - だし, オリジナルのソースファイル, `<tt>work</tt>' サブディレ - クトリ, およびpackageは含みません) をまとめて - <tt>.tar.gz</tt> ファイルにし, -<tscreen><verb> -ftp://ftp.FreeBSD.ORG/pub/FreeBSD/incoming/ -</verb></tscreen> - へ置き, <tt>send-pr(1)</tt> を使って私たちのところにメールを送っ - てください (categoryは `ports', classは `change-request' を - 使ってください). 私たちは, 何か不明な点があったらあなたに確 - 認したのち, それをツリーへ置きます. あなたの名前は, FreeBSD - ハンドブックやその他のファイルの `Additional FreeBSD - contributors' のリストにも載るでしょう. う〜ん, 素晴らし - い. <tt>:)</tt> - - <sect2> - <heading>本格的なport</heading> - - <p>残念ながら, 移植がそう簡単ではなく, 動かすために多少の変更が - 必要な場合も多いでしょう. この節では, portsコレクション - の方法論にのっとって, そのような場合にどのように変更を施し, 動 - くようにしたらよいかを順を追って説明します. - - <sect3> - <heading>port構築の詳細</heading> - - <p>まず, あなたがportのディレクトリで `<tt>make</tt>' とタイ - プしてから起こる一連の出来事について,順を追って説明しま - す. ここを読むときには, 他のウィンドウで同時に - <tt>bsd.port.mk</tt>も開いておくとよいかもしれません. - - <p>しかし, <tt>bsd.port.mk</tt>が何をしているのか, 完全に理解 - できなくても心配する必要はありません. そう多くの人が理解して - いるわけではないですから... <tt>f(^_^;)</tt> - - <enum> - <item>まず, fetchというターゲットが実行されます. このfetchターゲッ - トはローカルディスクの<tt>${DISTDIR}</tt>に配布ファ - イルがあるようにするのが役目です. もし, fetchが必要なファ - イルを<tt>${DISTDIR}</tt>に見つけることができなけ - れば, Makefileに指定されているURL - <tt>${MASTER_SITES}</tt>, そして私たちのFTPサイトで - ある <htmlurl - url="ftp://ftp.freebsd.org/pub/FreeBSD/distfiles/" - name="ftp://ftp.freebsd.org/pub/FreeBSD/distfiles/"> (ここ - には, 私たちが取ってきたファイルをバックアップとして置いてあ - ります) に探しにいきます. そして, ユーザのサイトがインター - ネットに直接接続されている場合には, - <tt>${FETCH}</tt> を使って, その名前のファイルを取っ - てきて, <tt>${DISTDIR}</tt>に保存します. - - <item>次に実行されるのはextractターゲットです. これは, - <tt>${DISTDIR}</tt>にある, 配布ファイル (普通は - gzipされたtarファイル) を読み, ソースを一時的な作業ディレ - クトリ<tt>${WRKDIR}</tt> (デフォルトは - <tt>work</tt>) に展開します. - - <item>次に, patchというターゲットが実行されます. まず, - <tt>${PATCHFILES}</tt>に定義されている, すべてのパッ - チをあてます. 次にもし<tt>${PATCHDIR}</tt> (デフォ - ルトは<tt>patches</tt> サブディレクトリ) にパッチが存在す - れば, これらをアルファベット順にあてます. - - <item>次に実行されるターゲットはconfigureです. これには, い - ろいろな場合があります. - - <enum> - - <item>もし存在すれば, <tt>scripts/configure</tt> が実行されます. - - <item>もし, <tt>${HAS_CONFIGURE}</tt> あるいは - <tt>${GNU_CONFIGURE}</tt> がセットされていれば, - <tt>${WRKSRC}/configure</tt> が実行されます. - - <item>もし, <tt>${USE_IMAKE}</tt> がセットされていれば, - <tt>${XMKMF}</tt> (デフォルト: `<tt>xmkmf - -a</tt>') が実行されます. - - </enum> - - <item>最後に, buildというターゲットが実行されます. これは, そのport - の専用の作業ディレクトリ (<tt>${WRKSRC}</tt>) にい - き, コンパイルするのが役目です. もし - <tt>${USE_GMAKE}</tt> がセットされていれば, GNU - <tt>make</tt>が使用されます. さもなければFreeBSDの - <tt>make</tt>が使用されます. - - </enum> - - <p>上記はデフォルトのルールです. さらに, `<tt>pre-<何とか - ></tt>や `<tt>post-<何とか></tt>' というターゲット - が定義してあったり, そのような名前のスクリプトが - <tt>scripts</tt> サブディレクトリに置いてある場合には, それ - らはデフォルトの動作の前後に実行されます. - - <p>たとえば, <tt>post-extract</tt>というターゲットがMakefile - で定義されていて, <tt>pre-build</tt>というファイルが, - <tt>scripts</tt>サブディレクトリにあるとすると, - <tt>post-extract</tt>ターゲットは, 通常の展開動作のあとに呼 - び出され, <tt>pre-build</tt>スクリプトはデフォルトのコンパイ - ルのルールが実行される前に実行されます. もし動作が簡単であれ - ば, Makefileのターゲットを使用することが推奨されています. な - ぜならば, そのportが何らかのデフォルトではない動作を必要とす - るのかどうかが一箇所にまとめて書いてあった方が他の人に理解しやす - いからです. - - <p>デフォルトの動作は<tt>bsd.port.mk</tt> の - `<tt>do-<何とか></tt>' というターゲットでおこなわれます. - たとえば, portを展開するコマンドは, `<tt>do-extract</tt>' - というターゲットにあります. もし, デフォルトのターゲットに - 不満があれば, `<tt>do-<something></tt>' というターゲッ - トを再定義することによって, どのようにでも直すことができます. - - <p>「メイン」のターゲット (例えば, <tt>extract</tt>, - <tt>configure</tt>等) は, すべての前段階が実行されていること - を確認して, 実際のターゲットやスクリプトを呼び出す以外のこと - はしません. bsd.port.mkはこれらが変更されることは仮定してい - ませんので, もし, 例えば, 展開の仕方を直したいときには, - <tt>do-extract</tt> を直し, 絶対に<tt>extract</tt>には手を - 触れないでください. - - <p>これで, ユーザが `<tt>make</tt>' と入力したときに何が起こ - るのかが理解できたと思います. では, 完璧なportを手順を追っ - て作ってみましょう. - - <sect3> - <heading>オリジナルのソースの入手</heading> - - <p>オリジナルのソースを, (普通は) 圧縮されたtarファイルの形 - (<tt><foo>.tar.gz</tt>あるいは - <tt><foo>.tar.Z</tt>) で入手して, それを - <tt>${DISTDIR}</tt> にコピーします. 可能なかぎり, 広 - く使われている<em>主流の</em>ソースを使用するようにしてください. - - <p>もし, ネットワークへの接続のよいFTP/HTTPサイトを見つけるこ - とができなかったり, 頭にくるような非標準的な形式しか持ってい - ないサイトしか見つけられないときには, 最後の手段として, 私たち - 自身で, -<tscreen><verb> -ftp://freefall.FreeBSD.ORG/pub/FreeBSD/LOCAL_PORTS/ -</verb></tscreen> - に置くことができます. これについての問い合わせのメールは - は &a.ports へお願いします. - - <p>もし, あなたのportに必要ないくつかの追加パッチがインター - ネット上で手に入るのならば, それらも取ってきて, - <tt>${DISTDIR}</tt> に置きます. もし, それらがメイン - のソースのtarファイルとは別のサイトにあっても, 心配する必要 - はありません. そのような状況にはちゃんと対応できるようになっ - ています. (以下の<ref id="porting:patchfiles" - name="${PATCHFILES}の記述">をご覧く - ださい). - - <sect3> - <heading>Portの修正</heading> - - <p>適当なディレクトリにtarファイルを展開して, FreeBSDの最新の - バージョン上で, 正しくコンパイルできるために必要なあらゆる変 - 更を施します. 最終的に処理は自動化するわけですから, 何をおこなっ - たかを<em>注意深く記録しておきましょう</em>. あなたのport - が完成した暁には, ファイルの削除, 追加, 修正を含むすべての処 - 理が, 自動化されたスクリプトやパッチファイルでおこなえるようになっ - ていないといけません. - - <p>もし, あなたのportのコンパイルやインストールのために必要 - な手作業があまりに多いようならば, Larry Wallの模範的な - Configureスクリプトでも参考にしたほうがいいかもしれませ - ん. 新しいportsコレクションは, 最小のディスクスペースで, - 個々のportがエンドユーザにできるだけ「プラグ & プレ - イ」の状態でmakeできることをめざしています. - - <p>注意: あなたが作成しFreeBSDのportsに寄付されたパッチファイル, - スクリプトおよびその他のファイルは，明示的に記述されている場合 - を除いては, BSDの標準的な著作権条件によりカバーされていると見な - されます． - - <sect3> - <heading>パッチをあてる</heading> - - <p>portの過程で追加されたり変更されたファイルは再帰的diffで変 - 更点を取り出すことができます. パッチは適当にまとめて, - `<tt>patch-<xx></tt>' という名前のファイルに入れてくだ - さい. <tt><xx></tt>はパッチが適用される順番を示します -- - これらは, <em>アルファベット順</em>, つまり `<tt>aa</tt>' が - 最初, つぎに `<tt>ab</tt>' などとなります. これらのファイル - を<tt>${PATCHDIR}</tt>に置いておくと, 自動的に適用さ - れるようになっています. すべてのパッチは - <tt>${WRKSRC}</tt> (通常は, portのtarファイルが展 - 開されるところで, makeが実行されるところと同じです) からの相 - 対パスになります. 修正やアップグレードを容易にするため, 2つ - 以上のパッチが同じファイルを修正するのは避けてください. (例, - patch-aaとpatch-abが共に<tt>${WRKSRC}</tt>/foobar.c - を修正する, など.) - - <sect3> - <heading>コンフィグレーション</heading> - - <p>カスタマイズのために追加したいコマンドがあれば, - <tt>configure</tt>という名前のスクリプトに入れて - `<tt>scripts</tt>' サブディレクトリに置きます. 上で述べたよ - うに, <tt>pre-configure</tt> あるいは<tt>post-configure</tt> - というMakefileのターゲットおよび/あるいはスクリプトで処理す - ることもできます. - - <sect3> - <heading>ユーザからの入力の扱い</heading> - - <p>もし, そのportがビルド, コンフィグレーション, インストー - ルの際にユーザからの入力を必要とするならば, Makefileで - <tt>IS_INTERACTIVE</tt>をセットしてください. これによって, - 深夜, 自動的にたくさんのportをコンパイルすることが可能にな - ります. 環境変数<tt>BATCH</tt>がセットされていると - <tt>IS_INTERACTIVE</tt>の定義されているportはスキップされ - ます (そして, ユーザが<tt>INTERACTIVE</tt>という変数をセッ - トすると入力を必要とするport<em>のみ</em>コンパイルされま - す). - - <sect2> - <heading>Makefileの作成</heading> - - <p>Makefileの作成は非常に単純です. 繰り返しになりますが, 始める - まえに, すでにある例を見てみることをお奨めします. またこのハ - ンドブックには<ref id="porting:samplem" name="Makefileのお手本"> - があります. それを見て, Makefile内の変数の順番や空行を入れると - ころなどの参考にしてください. そうすると他の人々にも読みやすい - ものとなります. - - <p>では, Makefileをデザインするときに問題となるところを順に追っ - て見てみましょう. - - <sect3> - <heading>オリジナルのソース</heading> - - <p>ソースは<tt>${DISTDIR}</tt>に, 標準的なgzipされた - tarファイルとして置かれていますか? そうであれば, 次のステッ - プに進めます. そうでなければ, 変数 - <tt>${EXTRACT_CMD}</tt>, - <tt>${EXTRACT_BEFORE_ARGS}</tt>, - <tt>${EXTRACT_AFTER_ARGS}</tt>, - <tt>${EXTRACT_SUFX}</tt>, - <tt>${DISTFILES}</tt>を適当に書き換えないといけません. - どれだけ変更しないといけないかは, あなたのportの - 配布ファイルがどの程度標準からかけはなれているかによりま - す. (最もよくある場合は, gzipではなく普通のcompressコマンド - でtarファイルが圧縮されている場合で, - `<tt>EXTRACT_SUFX=.tar.Z</tt>' とするだけです.) - - <p>最悪の場合には, 自分で `<tt>do-extract</tt>' ターゲットを作 - 成して, デフォルトを上書きすることもできます. しかし, そこま - でする必要があることはめったにないでしょう. - - <sect3> - <heading>DISTNAME</heading> - - <p><tt>${DISTNAME}</tt>にはportの名前の基幹部分を入れ - ます. デフォルトのルールでは, 配布ファイルのリスト - (<tt>${DISTFILES}</tt>) は - <tt>${DISTNAME}${EXTRACT_SUFX}</tt>という名前 - になっています. 例えば, `<tt>DISTNAME=foozolix-1.0</tt>'の場 - 合, 通常のtarファイルだと, -<tscreen><verb> -foozolix-1.0.tar.gz -</verb></tscreen> - のようになります. - - さらにデフォルトのルールでは, tarファイルは - <tt>work/${DISTNAME}</tt>というサブディレクトリ - に展開されることを仮定しています, 例えば -<tscreen><verb> -work/foozolix-1.0/ -</verb></tscreen> - といった具合いです. - - これらの動作はもちろんすべて変更可能です. デフォルトのルー - ルは最も標準的な場合を仮定しているだけです. まず, portが複 - 数の配布ファイルを必要とするときには, 単に明示的に - <tt>${DISTFILES}</tt>を設定してください. もし, - <tt>${DISTFILES}</tt>の一部だけが実際に展開される場合 - には, それらを<tt>${EXTRACT_ONLY}</tt> に設定してくだ - さい. この変数が定義されている場合には, 展開時に - <tt>${DISTFILES}</tt>に優先して利用されます. 残りのファ - イルも<tt>${DISTDIR}</tt>に取ってきますが, 展開時に - はなにもせずに後で使うためにそのまま置いておかれます. - - <sect3> - <heading>CATEGORIES (分類)</heading> - - <p>完成したpackageの実体は<tt>/usr/ports/packages/All</tt> - に置かれます. また, 1つかそれ以上の - <tt>/usr/ports/packages</tt>のサブディレクトリからのシンボリッ - クリンクが作られます. それらのサブディレクトリの名前が - <tt>${CATEGORIES}</tt>という変数によって指定されます. - これは, ユーザがFTPサイトやCD-ROMのpackageの山を渡り歩 - くことを容易にするためです. 現在存在するカテゴリを見て, そ - のportに適したもを選んでください. (<htmlurl - url="http://www.freebsd.org/ports/" name="Ports Collection - のページ">などが参考になるでしょう). もしそのportが本当 - に現在存在するすべてのものとは異なっている場合には, 新しいカテ - ゴリ名を作ることもできます. - - <sect3> - <heading>MASTER_SITES</heading> - - <p>オリジナルの配布ファイルを指し示すFTPまたはHTTPのURLのディ - レクトリ部分までを<tt>${MASTER_SITES}</tt>に記録しま - す. スラッシュ (<tt>/</tt>) を最後につけることをお忘れなく. - - <p>配布ファイルがシステム上に存在しないときに, makeマクロは - <tt>${FETCH}</tt>でこの変数に指定されたサイトから取っ - てきます. - - <p>複数の, できれば異なる大陸のサイトをこのリストに入れておく - ことが推奨されています. これによって, 広域ネットワークにトラ - ブルがあった場合でも成功する可能性が高くなります. 私たちはさら - に, 自動的に最も近いマスタサイトを検出して, そこから取って - くるメカニズムの導入を計画しています. - - <p>オリジナルのtar ファイルが, X-contrib, GNU, Perl CPAN, TeX CTAN - または Linux Sunsite などの有名なアーカイブにある場合には, - MASTER_SITE_XCONTRIB, MASTER_SITE_GNU, - MASTER_SITE_PERL_CPAN, MASTER_SITE_TEX_CTAN および - MASTER_SITE_SUNSITE を利用することで, 簡単にこれらのサイトを - 指定することができます. あとは MASTER_SITE_SUBDIR にアーカイ - ブ内でのパスを指定するだけです. 以下に例を示します. -<tscreen><verb> -MASTER_SITES= ${MASTER_SITE_XCONTRIB} -MASTER_SITE_SUBDIR= applications -</verb></tscreen> - <p>ユーザは<tt>/etc/make.conf</tt>中で MASTER_SITE_* 変数を設定 - することによって, デフォルトの FTP サイトではなく, これらの - 有名なアーカイブのミラーの中で好みのものを使用することが可能 - です. - - <sect3> - <heading>PATCHFILES<label id="porting:patchfiles"></heading> - - <p>もし, オリジナルの配布ファイル以外にもFTPかHTTPで手に入る - パッチが必要な場合には, <tt>${PATCHFILES}</tt>にファ - イル名を, <tt>${PATCH_SITES}</tt>にサイトとディレクト - リの名前を<tt>${MASTER_SITES}</tt>と同様に設定してく - ださい. - - <p>そのパッチ内のファイル名ががソースツリーの一番上のディレク - トリ (<tt>${WKRSRC}</tt>) からの相対パスになっていな - い場合には, <tt>${PATCH_DIST_STRIP}</tt>を指定してく - ださい. 例えば, パッチ内のファイル名にすべて余計な - `<tt>foozolix-1.0/</tt>' がついている場合には, - `<tt>PATCH_DIST_STRIP=-p1</tt>'としてください. - - <p>これらのパッチは圧縮されていても大丈夫です. ファイル名が - `<tt>.gz</tt>' か `<tt>.Z</tt>' で終わる場合には自動的に復元 - されるようになっています. - - <p>もしパッチが, 文書などその他のファイルと一緒にgzipされた - tarファイルで配布されている場合には，単純に - <tt>${PATCHFILES}</tt> を使うことはできません. - このような場合には, このパッチの tar ファイルの名前と場所を - <tt>${DISTFILES}</tt> と <tt>${MASTER_SITES}</tt> - に加えます. それから, <tt>pre-patch</tt> ターゲットで, - パッチコマンドを走らせるか, パッチファイルを - <tt>${PATCHDIR}</tt> ディレクトリに - <tt>patch-<xx></tt>という名前でコピーするかして, - パッチを適用するようにします．(普通の gzip か compress された - tar ファイルであれば，通常のソースファイルと一緒にその時までに - 展開されていますので，明示的に展開する必要はありません．) - もし，後者の方法を使用する場合には，すでにそのディレクトリにある - なにかを上書きしないように, 注意する必要があります. - さらに, <tt>pre-clean</tt> ターゲットにコピーしたパッチファイル - を削除するコマンドを追加するのを忘れないでください. - - <sect3> - <heading>MAINTAINER</heading> - - <p>あなたのメールアドレスをここに入れてください. お願いします. - <tt>:)</tt> - - <p>保守担当者(maintainer)の責任についての詳細は， - <ref id="policies:maintainer" name="Makefile 中の MAINTAINER"> - の節をご覧ください． - - <sect3> - <heading>依存関係</heading> - - <p>このプログラムが他のportに依存する場合には, 必要なものが - 自動的に作られるようにすることができます. そのために, 以下の - 5つの変数が用意されています. - - <sect4> - <heading>LIB_DEPENDS</heading> - - <p>Portが必要とする非標準の共有ライブラリをこの変数で指定 - します. これは `<tt>lib:dir</tt>' という組のリストで, うち - <tt>lib</tt> が共有ライブラリの名前, そして<tt>dir</tt> - がそのライブラリが見つからない場合にインストールするport - のあるディレクトリです. 例えば, -<tscreen><verb> -LIB_DEPENDS= jpeg\\.6\\.:${PORTSDIR}/graphics/jpeg -</verb></tscreen> - と指定してあれば, まずメジャーバージョンが6のjpegライブ - ラリがあるかどうか確認し, ない場合にはportsツリーの中の - <tt>graphics/jpeg</tt> というサブディレクトリに移動し, そこ - からインストールしようとします. - - 前半の<tt>lib</tt> 部分はそのまま `<tt>ldconfig -r | - grep</tt>' へ引数として渡されることに注意してください. 特 - に, ピリオド (.) の前には上記の例のようにバックスラッシュ - を連続してつける必要があります. - - この依存関係は<tt>extract</tt> ステージのはじめでチェック - されます. また, packageを作るときに必要となるportのpackage名 - が記録され, <tt>pkg_add</tt>を使用すると自動的にそちら - のpackageもインストールされるようになります. - - <sect4> - <heading>RUN_DEPENDS</heading> - - <p>Portを使用する際に必要となるファイルまたはプログラムがある - ときにはこの変数で指定します. これは`<tt>path:dir</tt>' とい - う組のリストで, <tt>path</tt> がファイルまたはプログラムの - 名前, そして<tt>dir</tt> がそれが見つからない場合に作成する - ためのディレクトリ名です. <tt>Path</tt> の最初の文字がスラッ - シュ (<tt>/</tt>) の場合にはファイルとみなし, その存在を - `<tt>test -e</tt>' でチェックします; そうでない場合にはプ - ログラムであると仮定し, `<tt>which -s</tt>' を使ってそのプ - ログラムがユーザのサーチパス上にあるかどうか確認します. - - <p>例えばMakefileに以下のように書いてあるとします. -<tscreen><verb> -RUN_DEPENDS= ${PREFIX}/etc/innd:${PORTSDIR}/news/inn \ - wish:${PORTSDIR}/x11/tk -</verb></tscreen> - まず, `<tt>/usr/local/etc/innd</tt>' というファイルが存在 - するか確認し, ない場合にはportsツリーの中の - <tt>news/inn</tt> というサブディレクトリから作られます. ま - た, `<tt>wish</tt>' というプログラムがユーザのサーチパス中 - にあるかどうか探し, ない場合には同じくportsツリーの - <tt>x11/tk</tt> というサブディレクトリから作られます. - (この例で, `<tt>innd</tt>' は実際にはプログラムです; この - ように, プログラムであっても標準のサーチパス以外のところに - あるようなものの場合には, 絶対パスで指定してください.) - - この依存関係は<tt>install</tt> ステージのはじめでチェック - されます. また, packageを作る際に必要となるportのpackage名 - が記録され, <tt>pkg_add</tt>を使用すると自動的にそちら - のpackageもインストールされるようになります. - - <sect4> - <heading>BUILD_DEPENDS</heading> - - <p>Portのコンパイルに必要なファイルまたはプログラムがある - ときは, この変数で指定してください. <tt>RUN_DEPENDS</tt>と同 - 様に, これは `<tt>path:dir</tt>' という組のリストです. 例 - えば, -<tscreen><verb> -BUILD_DEPENDS= unzip:${PORTSDIR}/archivers/unzip -</verb></tscreen> - は `<tt>unzip</tt>' という名前のプログラムを探し, 見つから - ない場合には<tt>archivers/unzip</tt> サブディレクトリで作 - れという意味になります. - - ここでは「コンパイル」と一口にいいましたが, この変数は実際 - にはファイルの展開から実際のコンパイル・リンクまで全部をま - とめて面倒を見てくれます. この依存関係は<tt>extract</tt> - ステージからチェックされます. - - <sect4> - <heading>FETCH_DEPENDS</heading> - - <p>この変数は, portを取ってくるのに必要なファイルまたはプロ - グラムを指定するのに使います. 上の二つと同様に, これは - `<tt>path:dir</tt>' という組のリストです. 例えば, -<tscreen><verb> -FETCH_DEPENDS= ncftp2:${PORTSDIR}/net/ncftp2 -</verb></tscreen> - としておけば, `<tt>ncftp2</tt>' という名前のプログラムを探 - し, 見つからない場合には<tt>net/ncftp2</tt> サブディレク - トリにいってインストールします. - - この依存関係は<tt>fetch</tt>ステージからチェックされます. - - <sect4> - <heading>DEPENDS</heading> - - <p>上の四つのいずれにもあてはまらないような依存関係がある場 - 合, または他のportのソースが展開されている必要がある場合 - (インストールされているだけでは不十分な場合) にはこの変数 - を使います. これはディレクトリ名のリストです (上の四つと違っ - て特に「確認」するものがありませんので). - - <sect3> - <heading>コンパイル時の特別な指定</heading> - - <p>GNUの<tt>make</tt>を使う場合には, `<tt>USE_GMAKE=yes</tt>' - と指定してください. PortにGNUの<tt>configure</tt>が含まれ - ている場合には, `<tt>GNU_CONFIGURE=yes</tt>' を使います. GNU - <tt>configure</tt>にデフォルトの - `<tt>--prefix=${PREFIX}</tt>' 以外の引数を渡したい場 - 合には追加部分を<tt>${CONFIGURE_ARGS}</tt>で指定して - ください. - - <p>X Window Systemのアプリケーションなど, <tt>imake</tt>を - 使ってImakefileからMakefileを作成するportの場合には - `<tt>USE_IMAKE=yes</tt>' を指定してください. コンフィグレー - ションステージで自動的に<tt>xmkmf -a</tt> が実行されます. も - し `<tt>-a</tt>' フラグが問題をもたらすなら, さらに - `<tt>XMKMF=xmkmf</tt>'としてください. - - <p>PortのMakefileが `<tt>all</tt>' 以外のものをメインのター - ゲットとしている場合には, <tt>${ALL_TARGET}</tt> でそ - れを指定してください. `<tt>install</tt>' と - <tt>${INSTALL_TARGET}</tt> も同様です. - - <sect3> - <heading>NO_INSTALL_MANPAGES</heading> - - <p>あなたのportがimakeは使うものの `<tt>install.man</tt>' - ターゲットを持っていない場合, - `<tt>NO_INSTALL_MANPAGES=yes</tt>' を指定してください. つい - でに, 作者を探し出して八つ裂きにするといいでしょ - う. <tt>(-_-#)</tt> - - <sect2> - <heading>Motifを必要とするport</heading> - - <p>最近はコンパイルにMotifを必要とするアプリケーションが増えて - きました. (Motif自体は有料のものがいくつかの会社から手に入りま - すし, 無料の互換ライブラリを作ろうとしているグループが少なくと - も一つあります.) Motifはかなり広く使われていますし, 製品のライ - センスではライブラリを静的にリンクした実行形式は再配布が認めら - れている場合が多いので, Motifを必要とするソフトウェアを簡単に - 動的/静的にリンクできるようなしくみが用意されています. - - <sect3> - <heading>REQUIRES_MOTIF</heading> - - <p>MotifがないとコンパイルできないportのMakefileではこの変 - 数を指定してください. これによって, Motifを持っていない人が - このportをコンパイルしようとするのを未然に防ぎます. - - <sect3> - <heading>${MOTIFLIB}</heading> - - <p>この変数は<tt>bsd.port.mk</tt>によってMotifライブラリの指 - 定に置き換えられます. ソース内のMakefileやImakefileで - Motifライブラリを指定しているところをこの変数に置き換えるよ - うにパッチをあててください. - - <p>代表的な例としては以下の二つがあげられます: - <enum> - <item>MakefileかImakefileの中でMotifライブラリが - `<tt>-lXm</tt>' として使われている場合には, かわりに - `<tt>${MOTIFLIB}</tt>' と書いてください. - - <item>Imakefileの中で `<tt>XmClientLibs</tt>' が使われている - 場合には, それを `<tt>${MOTIFLIB} - ${XTOOLLIB} ${XLIB}</tt>' と書きかえてください. - </enum> - - <p><tt>${MOTIFLIB}</tt> は通常 `<tt>-L/usr/X11R6/lib - -lXm</tt>' か `<tt>/usr/X11R6/lib/libXm.a</tt>' に置き換えら - れます. したがって前に `<tt>-L</tt>' や `<tt>-l</tt>' をつけ - る必要はありません. - - <sect2> - <heading>ライセンス上の問題</heading> - - <p>ソフトウェアによっては制限の厳しいライセンスがついてきたり, - 法律的に問題があるものがあります (PKPの公開鍵暗号化, ITAR (暗 - 号化ソフトウェアの輸出) などが例としてあげられます). それらを - どう扱えばいいかはライセンスの文面によってさまざまな場合があり - ます. - - <p>ソフトウェア移植者として, あなたにはライセンスをよく読み, - FreeBSDプロジェクトがFTPまたはCD-ROMで配布してはいけないソフ - トウェアを配布してしまうことのないよう, 注意する義務があります. - なにか疑問がある場合には, &a.ports;に聞いてみてください. - - <p>よく見られるケースに対処するために, 二つの変数が用意されてい - ます: - - <enum> - <item>ソフトウェアに「有償再配布を禁ずる」という趣旨のライセン - スがついてきた場合には<tt>NO_CDROM</tt>という変数をセットして - ください. 私たちはこれがついているportはCD-ROMリリースに入 - れないようにしますが, オリジナルのソースファイルとpackage - はFTPでは取れるようにしておきます. - - <item>もしも, 生成される package が個々のサイトで独自に構築さ - れる必要があったり, ライセンスによって生成されるバイナリが - 配布できない場合には, <tt>NO_PACKAGE</tt> 変数を設定してくだ - さい. そのような package が FTP サイトに置かれたり, リリース - 時の CD-ROM へ入らないようにします. ただし, いずれの場合も - distfile は(FTP や CD-ROM に)含まれるようになります. - - <item>Portが, 使用者によっては法律上の問題が生じる時 (暗号化ソフ - トウェアなど), または「商用利用を禁ずる」とライセンスに書い - てある場合には<tt>RESTRICTED</tt>という変数にその理由を入れ - てください. この場合には, ソースファイルやpackageは私たちの - FTPサイトにも置かれません. - </enum> - - <p>注: GNU一般公有使用許諾書 (GPL) はバージョン1, 2とも - port作成上は何ら問題にはなりません. - - <p>注: もしあなたが，ソースツリー管理者 (committer) であれば， - ソースツリーにこのようなportを入れる際に, - <tt>ports/LEGAL</tt>ファイルを書き換えるのを忘れないようにし - てください. - - <sect2> - <heading>アップグレード</heading> - - <p>Portのバージョンが原作者からのものに比べて古いことに気がつ - いたら, まずはあなたの持っているportが私たちの最新のもの (ミラー - サイトの<tt>ports-current</tt>というディレクトリにあります) - であることを確認してください. - - <p>次に, portのMakefileに<tt>MAINTAINER</tt> (保守担当者) の - アドレスが書いてある場合には, その人にメールを出してみましょう. - 保守担当者の人がすでにアップグレードの準備をしているかもしれま - せんし, (新しいバージョンの安定度に問題があるなど) あえてアッ - プグレードをしない理由があるのかもしれません. - - <p>保守担当者にアップグレードをしてくれと頼まれた場合, あるいは - そもそもportのMakefileに保守担当者が書いてない場合などは, あ - なたがアップグレードをしてくださると助かります. その場合にはアッ - プグレードをしたのち, 変更前と変更後のディレクトリの再帰的diff - をとって送ってください. (例えば, 変更前のディレクトリが - `<tt>superedit.bak</tt>' という名前でとってあり, 変更後のもの - が `<tt>superedit</tt>' に入っているなら, `<tt>diff -ru - superedit.bak superedit</tt>' の結果を送ってください. ) - diff の出力を見て, すべての変更が正しくなされているか確認してください. - 変更箇所については, <tt>send-pr</tt> に diff の出力結果を入れて私たち - に送ってもらうのが一番よいです. commit する際に CVS に明確に記述しな - ければならないので, 付け加えたり削除したりしたファイルがあったら, - それについて書いておいてください. - - <sect2> - <heading>やっていいことといけないこと</heading> - - <p>この節では, ソフトウェアをportする上でよくある落し穴などにつ - いて説明します. - - <sect3> - <heading>WRKDIR</heading> - - <p>大事なファイルを<tt>work</tt>サブディレクトリに置き忘れな - いようにしてください. うっかり `<tt>make clean</tt>' とやっ - たらこのディレクトリはその下のファイルとともに<em>あとかたも - なく</em>消え去ってしまいます! スクリプトやパッチ以外に必要 - なファイルがある場合には, <tt>files</tt>というサブディレクト - リに入れ, <tt>post-extract</tt>ターゲットで<tt>work</tt>サ - ブディレクトリにコピーするようにしてください. - - <sect3> - <heading>Package情報</heading> - - <p>Package情報, すなわち<tt>pkg</tt>ディレクトリ内の三つ - のファイルは必ず用意してください. これらはpackageを作る以 - 外にもいろいろ使われていますので, - <tt>${NO_PACKAGE}</tt>が指定してあってpackageを作 - るのが禁止してあるportの場合でも<em>必ず</em>必要です. - - <sect3> - <heading>マニュアルの圧縮, バイナリのstrip</heading> - - <p>マニュアルは圧縮し, バイナリはstripしてください. オリジナル - のソースがバイナリを stripしてくれる場合は良いですが, - そうでない場合には <tt>post-install</tt>ターゲットを指定して - strip するようにするとよいでしょう. 例えば, こんな風になりま - す: -<tscreen><verb> - post-install: - strip ${PREFIX}/bin/xdl -</verb></tscreen> - <p>インストールされた実行形式がすでにstripされているかどうか - は<tt>file</tt>コマンドで確認できます. これが`not stripped' - と言わなければ, stripされているということです. - - <p>MAN[1-9LN] 変数を使用すると, マニュアルの圧縮を自動的に行う - ことができます. この方法を使うと, ユーザが - <tt>/etc/make.conf</tt>中で<tt>NOMANCOMPRESS</tt>を設定し, - マニュアルの圧縮を無効にしているかどうかを確認できます. - これらの変数の指定は, <tt>MAINTAINER</tt> の指定の後 - のセクションの一番最後で行ってください. こんな風に指定します: -<tscreen><verb> -MAN1= foo.1 bar.1 -MAN5= foo.conf.5 -MAN8= baz.8 -</verb></tscreen> - <p>なお, 普通 Imake を使ってコンパイルされる X アプリケーショ - ンの場合はこの指定は必要ありません. - - <p><tt>PREFIX</tt>以外のディレクトリの下にマニュアルを置く - ようなportでは<tt>MANPREFIX</tt>を指定することが - できます. さらに, 特定のセクションのマニュアルだけ, 標準では - ない場所にインストールする場合(例えば多くの Perl のモ - ジュールの ports の場合)には, 個々のマニュアルのパスを - <tt>MAN<em>sect</em>PREFIX</tt> (<em>sect</em>は, 1 から 9 - または, L か N を表わします) によって指定できます. - - <sect3> - <heading>INSTALL_* マクロ</heading> - <p> あなた自身の *-install ターゲットでファイルの正しいモードと - オーナを保証するために, 必ず<tt>bsd.port.mk</tt>で提供されて - いるマクロを使用してください. マクロは以下のようなものがあります. - - <itemize> - <item><tt>${INSTALL_PROGRAM}</tt> は実行可能なバイナリを - インストールするコマンドです． - <item><tt>${INSTALL_SCRIPT}</tt> は実行可能なスクリプトを - インストールするコマンドです． - <item><tt>${INSTALL_DATA}</tt> は共有可能なデータを - インストールするコマンドです． - <item><tt>${INSTALL_MAN}</tt> はマニュアルを - インストールするコマンドです．(圧縮をしません) - </itemize> - - <p>これらは基本的に<tt>install</tt>コマンドに適当なフラグを与え - たものです. どのようにこれらを使用するかは以下の例を見てください. - - <sect3> - <heading>INSTALL package スクリプト</heading> - <p>バイナリパッケージが pkg_add でインストールされるときに, 実行 - される必要があるコマンドがあれば, pkg/INSTALL スクリプトを使っ - て実行することができます. このスクリプトは自動的に package - に加えられ, pkg_add によって2度実行されます. はじめは - `<tt>INSTALL ${PKGNAME} PRE-INSTALL</tt>' と実行され, 2度目 - には, '`<tt>INSTALL ${PKGNAME} POST-INSTALL</tt>' と実行され - ます. どちらのモードで実行されているかは, `<tt>$2</tt>' - を調べることによってわかります. - 環境変数 `<tt>PKG_PREFIX</tt>' には package がインストールさ - れる directory が設定されます. 詳細は man - <tt>pkg_add(1)</tt> を見てください. - 注意すべきことは, port を `<tt>make install</tt>' で - インストールするときには, このスクリプトは自動的に実行されな - いということです. もし, 実行される必要があるならば, port の - Makefile で明示的に呼ぶ必要があります. - - <sect3> - <heading>REQ package スクリプト</heading> - <p>パッケージが(インストールされるシステムの状態によって) - インストールされるべきか, されないべきか区別する必要があると - きには, 「要件(requirements)」スクリプト pkg/REQ を作ること - ができます. これは, インストール及びデインストール - (package の削除)の時に自動的に実行され, それらが処理されるべ - きかを決定します. 詳細は, man <tt>pkg_create(1)</tt> と man - <tt>pkg_add(1)</tt> を見てください. - - <sect3> - <heading>付加的ドキュメント</heading> - - <p>普通のマニュアルやinfoファイルのほかにユーザにとって有用だ - と思えるようなドキュメントがある場合には, - <tt>${PREFIX}/share/doc</tt>の下にインストールしてく - ださい. これは前記と同様, <tt>post-install</tt>ターゲットの - 中からするのがいいでしょう. - - <p>まず, あなたのportのために新しいディレクトリを作りま - す. どのportのドキュメントか簡単にわかるような名前にする必 - 要がありますので, 普通は<tt>${PKGNAME}</tt>からバージョ - ン番号を除いた部分を使うといいでしょう. もちろん, ユーザが異 - なるバージョンのものを同時に使うことが予想されるportの場合 - には, <tt>${PKGNAME}</tt>をそのまま使ってかまいません. - - <p>ユーザが<tt>/etc/make.conf</tt>でこの部分を禁止するために - <tt>NOPORTDOCS</tt>という変数をセットしている場合には， - これらのドキュメントがインストールされないようにしてください. - こんな具合です. -<tscreen><verb> - post-install: - .if !defined(NOPORTDOCS) - ${MKDIR} -p ${PREFIX}/share/doc/xv - ${INSTALL_DATA} ${WRKSRC}/docs/xvdocs.ps ${PREFIX}/share/doc/xv - .endif -</verb></tscreen> - - <p>これらのファイルを<tt>pkg/PLIST</tt>に入れるのを忘れないよ - うにしてください. (packageが<tt>/etc/make.conf</tt>内の - 変数を読む方法は今のところ存在しませんので, - <tt>NOPORTDOCS</tt>については気にしないでください.) - - <p>(Packageの)インストールを行っているユーザに対してメッセージ - を表示したい場合には, そのメッセージを <tt>pkg/MESSAGE</tt> - に置くこともできます. この機能は, pkg_add したあとの - 追加のインストール手順や, ライセンス情報を表示するのに便利で - す. (注意: MESSAGE ファイルは pkg/PLIST に加える必要はありま - せん. - - <sect3> - <heading>DIST_SUBDIR</heading> - - <p><tt>/usr/ports/distfiles</tt>ディレクトリ内をあまり散らかさ - ないようにしてください. たくさんのファイルを取ってくるport - や, 数は少なくてもほかのportのファイルと混同されるおそれが - あるファイル (`Makefile' など) がある場合には, - <tt>${DIST_SUBDIR}</tt>にportの名前 - (<tt>${PKGNAME}</tt>からバージョン番号を取った部分を - 使うといいでしょう) を入れてください. すると, - <tt>${DISTDIR}</tt>がデフォルトの - <tt>/usr/ports/distfiles</tt>から - <tt>/usr/ports/distfiles/${DIST_SUBDIR}</tt>に変更さ - れ, 取ってきたファイルはすべてそのサブディレクトリの中に置か - れるようになります. - - <p>また, ファイルを取ってくるときにバックアップサイトとして使わ - れる<tt>ftp.freebsd.org</tt>のディレクトリ名にもこの変数の - 値が使われます. (<tt>${DISTDIR}</tt>を明示的に指定し - た場合には, ローカルのファイルを置くところは変わりますが, こ - のサイトのディレクトリ名は変わりませんので, 必ず - <tt>${DIST_SUBDIR}</tt>を使うようにしてください.) - - <p>この変数はMakefile中で明示的に指定された - <tt>${MASTER_SITES}</tt>には影響しないことに注意して - ください. - - <sect3> - <heading>フィードバック</heading> - - <p>Portを作るためにソフトウェアに変更を加えたら, なるべく原 - 作者にその旨を伝えてパッチ等を送ってください. これらが次のリ - リースに取り入れられれば, アップグレードが楽になります. - - <sect3> - <heading>RCS文字列</heading> - - <p>RCSが特別な意味を与えている文字列をパッチ内に入れないように - してください. ファイルを私たちのソースツリーに入れる時にこれら - の文字列はCVSによって書き換えられてしまい, あとでまたパッチ - を使おうとした時にうまくいかないことがあります. RCS文字列は - ドル記号 (`<tt>$</tt>') で囲まれており, - `<tt>$Id</tt>' や `<tt>$RCS</tt>' などで始まり - ます. - - <sect3> - <heading>パッチ作成上の注意</heading> - - <p><tt>diff</tt>の再帰 (`<tt>-r</tt>') フラグを使って再帰的なパッ - チを作るのは大変結構なのですが, でき上がったパッチは必ず目で - チェックして余計なゴミが入っていないことを確認してくださ - い. よくあるのはバックアップファイル同士の変更点, あるいは - imakeやGNU configureを使うソフトウェアのMakefileの変更点が - 入っている場合などです. また, ファイルをまるごと消す場合には - パッチを使わずに<tt>post-extract</tt>ターゲットで消す方が簡 - 単です. - - <sect3> - <heading>PREFIX</heading> - - <p>なるべくportは<tt>${PREFIX}</tt>に対する相対パス - にインストールすることができるように心がけてください. - この変数の値は<tt>${USE_IMAKE}</tt>か - <tt>${USE_X11}</tt>が指定してある時には - <tt>${X11BASE}</tt> (デフォルト<tt>/usr/X11R6</tt>), - そうでない場合には<tt>${LOCALBASE}</tt> - (デフォルト<tt>/usr/local</tt>) にセットされます. - - <p>サイトによってフリーソフトウェアがインストールされる場所が - 違いますので, ソース内で `<tt>/usr/local</tt>' や - `<tt>/usr/X11R6</tt>' を明示的に書かないようにしてくださ - い. Xのプログラムでimakeを使うものについては, これは問題に - はなりません. それ以外の場合には, ソース中のMakefileやスク - リプトで `<tt>/usr/local</tt>' (imakeを使わないXのプログラ - ムは `<tt>/usr/X11R6</tt>') と書いてあるところを - `<tt>${PREFIX}</tt>' に書き換えてください. この値は - portのコンパイル, およびインストール時に自動的に環境変数として - 下位makeに渡されます. - - <p>変数<tt>${PREFIX}</tt>の値はportのMakefileやユー - ザの環境で変更することもできます. しかし, 個々のportが - Makefileでこの変数の値を明示的に設定することはなるべくしない - でください. (X のプログラムでimakeを使用しないport - の場合は, <tt>USE_X11=yes</tt>としてください; これは - <tt>PREFIX=/usr/X11R6</tt>とするのとはかなり違います.) - - <p>また, 他のportからインストールされるプログラムやファイル - を指定するときには, 上で述べた変数を使用してください. 例えば, - <tt>less</tt>のフルパスを<tt>PAGER</tt>というマクロに入れた - い場合は, コンパイラに - <verb>-DPAGER=\"/usr/local/bin/less\"</verb>と渡すかわりに - <verb>-DPAGER=\"${PREFIX}/bin/less\"</verb> (Xを使う - portの時は - <verb>-DPAGER=\"${LOCALBASE}/bin/less\"</verb>) を渡し - てください. こうしておけば, `/usr/local' がまるごとどこか他 - の場所に移してあるサイトでも, あなたのportがそのまま使える - 可能性が高くなります. - - <sect3> - <heading>ディレクトリ構成</heading> - - <p>インストール時には<tt>${PREFIX}</tt>の正しいサブディ - レクトリにファイルを置くように心がけてください. ソフトウェア - によっては新しいディレクトリを一つ作ってファイルを全部それに - 入れてしまうものがありますが, それはよくありません. また, バ - イナリ, ヘッダファイルとマニュアル以外のすべてを - `<tt>lib</tt>'というディレクトリに入れてしまうportもあります - が, これもBSD的なファイルシステム構成からいうと正しくありま - せん. これは以下のように分散すべきです. `<tt>etc</tt>' にセッ - トアップ/コンフィグレーションファイル, `<tt>libexec</tt>' に - 内部で使用されるプログラム (コマンドラインから呼ばれることの - ないコマンド), `<tt>sbin</tt>' に管理者用のコマンド, - `<tt>info</tt>' に GNU Info 用のドキュメント, そして - `<tt>share</tt>' にアーキテクチャに依存しないファイルが入り - ます. 詳細については man <tt>hier(7)</tt> を見てくださ - い. <tt>/usr</tt>の構成方針はほとんどそのまま - <tt>/usr/local</tt>にもあてはまります. - - <sect3> - <heading>ldconfig</heading> - - <p>共有ライブラリをインストールするときには, 共有ライブラリのキャッ - シュを更新するためにportのMakefileの<tt>post-install</tt> - target から`<tt>/sbin/ldconfig -m</tt>' を走らせてください. - このコマンドの引数は共有ライブラリのインストールしてあるディ - レクトリ (通常 <tt>${PREFIX}/lib</tt>) です. - - <p>また, <tt>pkg/PLIST</tt>に<tt>@exec</tt>行を入れ, package - をインストールした場合にも共有ライブラリがすぐ使えるように - してください. この行は共有ライブラリを指定する行のすぐ後に書 - くのがいいでしょう: -<tscreen><verb> -lib/libtcl.so.7.3 -@exec /sbin/ldconfig -m %D/lib -</verb></tscreen> - - <p><em>絶対に</em>引数なしでただ `<tt>ldconfig</tt>'とだけ書い - てある行をMakefileやpkg/PLISTファイルに入れないでください. - このコマンドを実行すると, 共有ライブラリのキャッシュが - <tt>/usr/lib</tt>の内容のみとなり, ユーザのマシンにさまざま - な問題をもたらします (「ぎゃぁ! このportをインストールした - らxinitが使えなくなっちゃった!」). この掟を破った者は, 永久 - に地獄の底で苦しみ続けるように, 閻魔様に頼んでおきます. - - <sect3> - <heading>困ったら....</heading> - - <p>私たちに質問を送る前に, 既存のportの例と<tt>bsd.port.mk</tt>を - ちゃんと読んでください! <tt>;)</tt> - - <p>それでもわからないことがあったら, 一人で悩まないでどんどん - 質問してください! <tt>:)</tt> - - <sect2> - <heading>Makefileのお手本<label id="porting:samplem"></heading> - - <p>これはportのMakefileを作る際のお手本です. かぎかっこ - ([])内のコメントは忘れずに取ってください. - - <p>変数の順番, 段落の間の空行など, Makefileを作るときはなるべくこ - の形式にしたがってください. 既存のportのMakefileがすべてこの形 - 式にしたがっているわけではありませんが, 今後はなるべく統一していき - たいと考えています. この形式は重要な情報が簡単に見つけられるよ - うに設計されています. - -<tscreen><verb> - [ヘッダ -- どのようなportのMakefileかすぐにわかるようになっています] - # New ports collection makefile for: xdvi - # Version required: pl18 ["1.5alpha" みたいなのでも結構です] - # Date created: 26 May 1995 - [これはこのソフトウェアを最初にFreeBSDにportした人の名前, つまり, - このMakefileを書いた人です] - # Whom: Satoshi Asami <asami@FreeBSD.ORG> - # - # $Id$ - [ ^^^^ この部分は, CVS ツリーに入れる時に自動的に RCS の ID 文字列に - 置き換えられます.] - # - - [Port自体, およびオリジナルのソースを取ってくるところを記述する部分. - 最初は必ずDISTNAME, そして必要ならPKGNAME, CATEGORIES, 続いて - MASTER_SITESがおかれ, さらに MASTER_SITE_SUBDIR がおかれることもあり - ます. そのあと, EXTRACT_SUFX か DISTFILES を指定することも可能です] - DISTNAME= xdvi - PKGNAME= xdvi-pl18 - CATEGORIES= print - [最後のスラッシュを忘れないように ("/")!] - MASTER_SITES= ${MASTER_SITE_XCONTRIB} - MASTER_SITE_SUBDIR= applications - [ソースファイルが標準の ".tar.gz" 形式でない時にこれを使いましょう] - EXTRACT_SUFX= .tar.Z - - [配布パッチのセクション -- ない場合もあります] - PATCH_SITES= ftp://ftp.sra.co.jp/pub/X11/japanese/ - PATCHFILES= xdvi-18.patch1.gz xdvi-18.patch2.gz - - [保守責任者 -- これは *必ず* 必要です. 担当者 (あなた) 自身, あるいは - 担当者に素早く連絡をとれる人のアドレスを書いてください. どうしてもこ - こに自分のアドレスを書くのがいやな人は "ports@FreeBSD.ORG" と書いて - もいいです] - MAINTAINER= asami@FreeBSD.ORG - - [依存するport -- ない場合もあります] - RUN_DEPENDS= gs:${PORTSDIR}/print/ghostscript - LIB_DEPENDS= Xpm\\.4\\.:${PORTSDIR}/graphics/xpm - - [ここには標準のbsd.port.mkの変数で, 上のどれにもあてはまらないものを - 書きます] - [コンフィグレーション, コンパイル, インストールなどの時に質問をする - なら...] - IS_INTERACTIVE=yes - [${DISTNAME}以外のディレクトリにソースが展開されるなら...] - WRKSRC= ${WRKDIR}/xdvi-new - [配布されているパッチが ${WRKSRC} に対する相対パスで作られてい -ない場合にこの変数の指定が必要かも...] - PATCH_DIST_STRIP= -p1 - [GNU autoconfによって生成された "configure" スクリプトを走らせたいなら...] - GNU_CONFIGURE= yes - [/usr/bin/makeでなく, GNU makeを使わないといけないなら...] - USE_GMAKE= yes - [これがXのアプリケーションで "xmkmf -a" を走らせたいなら...] - USE_IMAKE= yes - [などなど] - - [下の方のルールで使う非標準の変数] - MY_FAVORITE_RESPONSE= "yeah, right" - - [そして, 特別なターゲット, 使用順に] - pre-fetch: - i go fetch something, yeah - - post-patch: - i need to do something after patch, great - - pre-install: - and then some more stuff before installing, wow - - [最後には必ず] - .include <bsd.port.mk> -</verb></tscreen> - - <sect2> - <heading>Packageの名前</heading> - - <p>Packageの名前は以下のルールにしたがってつけてください. こ - れはpackageのディレクトリを見やすくするためで, 無秩序な名前 - がたくさん並んでいるとユーザが使いづらくなるのではという心配か - らです. (FTPサイトなどにはたくさんpackageがありますからね.) - - <p>Packageの名前は以下のようにしてください. - -<tscreen><verb> -[<言語>-]<名前>[[-]<オプション>]-<バージョン.番号>; -</verb></tscreen> - - <tt>${DISTNAME}</tt> が上記の形式になっていない場合に - は, <tt>${PKGNAME}</tt> をそのようにしてください. - - <enum> - <item>FreeBSDはユーザの慣れ親しんだ言語のサポートに力を入れて - います. 特定の言語のためのportのpackage名には - `<言語>' に言語名の略称を入れてください. 例えば, 日本 - 語なら `jp', ロシア語なら `ru' といった具合です. - - <item>`<tt><名前></tt>' の部分は原則的にはすべて英小文字 - を使います. 例外はたくさんのプログラムが入っている巨大なport - の場合で, XFree86 (ほんとにあるんですよ) やImageMagickな - どがこれにあたります. そうでない場合には, 名前の大文字を小文 - 字に (少なくとも最初の一字だけは) 変えてください. また, その - ソフトウェアの名前として通常使われるものに番号, ハイフン, あ - るいは下線が入っている場合には, それらを使うことも構いません - (`kinput2' など). - - <item>コンパイル時に環境変数や<tt>make</tt>の引数などでいくつ - か別のオプションをつけてコンパイルできる場合, - `<compiled.specifics>' にそのオプションを入れてくださ - い (ハイフンはあってもなくてもかまいません). 用紙のサイズ, - あるいはフォントの解像度などがこれにあたります. - - <item>バージョン番号は数字とアルファベットからなり, ピリオド - (.) で区切ります. アルファベットは二文字以上続けてはいけませ - ん. ただ一つの例外は「パッチレベル」を意味する `pl' で, それ - 以外にバージョン番号がまったくついていない場合にのみ使うことがで - きます. - </enum> - - <p>では, <tt>${DISTNAME}</tt>を正しい - <tt>${PKGNAME}</tt>に直す例を見てみましょう: - -<tscreen><verb> -DISTNAME PKGNAME 理由 -mule-2.2.2 mule-2.2.2 まったく問題なし -XFree86-3.1.2 XFree86-3.1.2 同上 -EmiClock-1.0.2 emiclock-1.0.2 プログラム一つだけの時は小文字のみ -gmod1.4 gmod-1.4 `<名前>' のあとにハイフンが必要 -xmris.4.02 xmris-4.02 同上 -rdist-1.3alpha rdist-1.3a `alpha'のような文字列は使えない -es-0.9-beta1 es-0.9b1 同上 -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 jp-gawk-2.15.6 日本語バージョン -psutils-1.13 psutils-letter-1.13 コンパイル時に用紙のサイズを指定 -pkfonts pkfonts300-1.0 300dpiフォント用のpackage -</verb></tscreen> - - <p>オリジナルのソースにまったくバージョン情報が見当たらず, また原作 - 者が新しいバージョンをリリースする可能性が低いときには, バージョ - ン番号として `1.0' を使えばいいでしょう (上記のpiewmの例がこ - れにあたります). そうでない場合には, 原作者に聞くか, 日付 (`年. - 月.日') を使うなどしてください. - - <sect2> - <heading>やっとおしまい!</heading> - - <p>いやはや, 長い文章ですみません. ここまで読んでくださった方に - は感謝, 感謝でございます. <tt>(_ _)</tt> - - <p>さあ, portの作り方がわかったところで, 世界中のソフトウェア - をport化しましょう. FreeBSDプロジェクトに貢献するには, それ - がもっとも簡単な方法です! <tt>:)</tt> |
