[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Documentation/pkgsrc/fixes.xml: 1.1 -> 1.4
以下のページの更新をしました。ツッコミをお願いします。
Documentation/pkgsrc/fixes.xml: 1.1 -> 1.4
火曜日までに異議がなければ、 commit します。
以下、訳と原文の差分です。
--- Documentation/pkgsrc/fixes.xml.orig 2006-05-29 21:29:43.000000000 +0900
+++ Documentation/pkgsrc/fixes.xml 2006-05-29 21:29:43.000000000 +0900
@@ -1,24 +1,29 @@
-<!-- $NetBSD: fixes.xml,v 1.1 2004/06/06 13:31:54 grant Exp $ -->
+<!-- $NetBSD: fixes.xml,v 1.4 2004/09/29 13:08:36 hubertf Exp $ -->
<!-- Based on english version: -->
-<!-- NetBSD: fixes.xml,v 1.1 2004/06/06 13:31:54 grant Exp -->
+<!-- NetBSD: fixes.xml,v 1.4 2004/09/29 13:08:36 hubertf Exp -->
-<chapter id="fixes">
+<chapter id="fixes"> <?dbhtml filename="fixes.html"?>
<title>パッケージの修正に関する注意</title>
<sect1>
<title>CPP定義</title>
-
- <para>アプリケーションを&os;に移植するためには、コンパイラーがコンパイルしてい
+
+ <para>
+ アプリケーションをNetBSDに移植するためには、コンパイラーがコンパイルしてい
るシステムを判断する必要があります。したがって、Cのプリプロセッサーがシステ
- ムを判断できるように、CPPの定義を使います。</para>
+ ムを判断できるように、CPPの定義を使います。
+ </para>
- <para>4.4 BSDから派生したシステム上で作業しているかどうかをテストするためには、
+ <para>
+ 4.4 BSDから派生したシステム上で作業しているかどうかをテストするためには、
BSD定義を使用します。これは
- <filename><sys/param.h></filename>で定義されています。</para>
+ <filename><sys/param.h></filename>で定義されています。
+ </para>
<programlisting><![CDATA[#include <sys/param.h>]]></programlisting>
- <para>また、BSDに固有の部分を、以下の条件でかこむこともできます。</para>
+ <para>また、パッケージの C や C++ のコードのうち BSDに固有の部分を、
+ 以下の条件でかこむこともできます。</para>
<programlisting><![CDATA[#if (defined(BSD) && BSD >= 199306)
...
@@ -26,7 +31,7 @@
<para>どうか注意して<quote>__NetBSD__</quote>定義を使って下さい。4.4-liteから派生した他のBSDにな
い&os;固有の特徴にのみ適用してください。</para>
- </sect1>
+</sect1>
<sect1 id="fixes.libtool">
<title>共有ライブラリー - libtool</title>
@@ -73,6 +78,26 @@
マイナー番号がゼロの場合は、<quote>-version-info</quote>をかならず含めるようにしてくだ
さい。そうしないとlibtoolは共有ライブラリーのバージョンを取り除きます。</para>
+ <para> libtool のマニュアルより:</para>
+
+ <programlisting>
+ libtool のライブラリーのバージョンは、以下の三つの整数で表されます。
+
+CURRENT
+ このライブラリーが実装しているインターフェース番号のうち最新のもの。
+
+REVISION
+ CURRENT インターフェースの実装番号。
+
+AGE
+ このライブラリーが実装しているインターフェースの最新のものと最古のものの間の差。
+ すなわち、このライブラリーが実装しているのは、
+ `CURRENT - AGE' から `CURRENT' までの番号の範囲にある、
+ すべてのインターフェース番号です。
+
+ 二つのファイブラリーの CURRENT と AGE 番号がいずれも同じ場合、
+ダイナミックリンカーは REVISION 番号が大きいほうのライブラリーを選びます。</programlisting>
+
<para>また、<quote>-release</quote>オプションは、ある一つの場合に限って、a.outとELF(シンボ
リックリンクを除く)との間で異なる結果をもたらします。
<quote>libfoo-release.so.<emphasis>x</emphasis>.<emphasis>y</emphasis></quote>
@@ -98,7 +123,7 @@
ジョンが加えられないようにするため、<quote>-module -avoid-version</quote>を使ってくだ
さい。</para>
- <para><filename>PLIST</filename>には<filename>foo.so</filename>
+ <para><filename>PLIST</filename>ファイルには<filename>foo.so</filename>
の一覧が加わります。</para>
</listitem>
@@ -111,9 +136,7 @@
ことに注意してください。引数として<filename>.la</filename>ファイルを使うように修正しなければ
なりません。例えば、</para>
- <informalexample>
- <programlisting>${LIBTOOL} --mode=link ${CC} -o someprog -L../somelib -lsomelib</programlisting>
- </informalexample>
+ <programlisting>${LIBTOOL} --mode=link ${CC} -o someprog -L../somelib -lsomelib</programlisting>
<para>は、以下のように変更する必要があります。</para>
@@ -128,34 +151,46 @@
<quote>${LIBTOOL} --mode=install</quote>を書いて下さい。そしてライブラリーの名前を
<filename>.la</filename>に変えてください。例えば、以下のように書く必要があります。</para>
- <informalexample>
- <programlisting>${LIBTOOL} --mode=install ${BSD_INSTALL_DATA} ${SOMELIB:.a=.la} ${PREFIX}/lib</programlisting>
- </informalexample>
+ <programlisting>${LIBTOOL} --mode=install ${BSD_INSTALL_DATA} ${SOMELIB:.a=.la} ${PREFIX}/lib</programlisting>
<para>これは、静的リンクのための<filename>.a</filename>、共有ライブラリー、必要なシンボリックリンク
をインストールし、&man.ldconfig.8;を実行します。</para>
</listitem>
+
+ <listitem>
+ <para> <filename>PLIST</filename> に、
+ <filename>.a</filename>, <filename>.la</filename>,
+ <filename>.so</filename>, <filename>.so.CURRENT</filename>,
+ <filename>.so.CURRENT.REVISION</filename> ファイルをすべて含めます
+ (これは、以前のものから変わった点です)。 </para>
+ </listitem>
+
</orderedlist>
</sect1>
<sect1>
<title>すでにlibtoolをサポートしているGNUパッケージでlibtoolを使う</title>
- <para>パッケージの<emphasis>libtool</emphasis>を簡単に回避する方法として、
- <varname>USE_LIBTOOL=yes</varname>および
- <varname>LTCONFIG_OVERRIDE=${WRKSRC}/ltconfig</varname>をパッケージのMakefileに追加してくださ
- い。パッケージの<emphasis>libtool</emphasis>は、do-configureターゲットでltconfigスクリプトにより
- 作られます。<varname>USE_LIBTOOL</varname> および
- <varname>LTCONFIG_OVERRIDE</varname> が定義されている場合、指定
- されたltconfigは、パッケージのlibtoolのかわりに<pkg>devel/libtool</pkg>を使うよ
- う上書きされます。新しい(ltconfigを持たない)バージョンのlibtoolの場合は、上
- で説明したもののかわりに
- <varname>LIBTOOL_OVERRIDE=${WRKSRC}/libtool</varname>を使う必要がある
- かもしれません。</para>
+ <para><varname>USE_LIBTOOL=yes</varname> をパッケージの
+ Makefile に追加します。こうするとほとんどの場合、パッケージ固有の
+ libtool を無視します。古い libtool を使っているパッケージでは、
+ libtool はdo-configureターゲットでltconfigスクリプトにより作られます。<command>make
+ configure; find work*/ -name libtool</command>
+ のようにして、libtool スクリプトの場所を確認することができます。</para>
+
+ <para> <varname>LIBTOOL_OVERRIDE</varname> で、どの libtool
+ スクリプトを無視するかを、<varname>WRKSRC</varname> からの相対位置で指定します。
+ 指定しなかった場合、<quote>libtool */libtool
+ */*/libtool</quote> に設定されますので、パッケージ固有の libtool
+ スクリプトの場所がこのいずれとも異なる場合は、適宜設定してください。 </para>
+
+ <para> 静的ライブラリー <filename>*.a</filename>
+ の構築やインストールが必要ない場合は、かわりに
+ <varname>SHLIBTOOL_OVERRIDE</varname> を使います。 </para>
<para>パッケージが動的共有オブジェクトのロードに、libtool (libltdl)のプラットフォー
- ム独立なライブラリーを使う場合は、libtoolのbuildlink2.mkをインクルード(さら
- に、<varname>USE_BUILDLINK2=YES</varname>を設定)してください。</para>
+ ム独立なライブラリーを使う場合は、libtoolのbuildlink3.mkをインクルード(さら
+ に、<varname>USE_BUILDLINK3=YES</varname>を設定)してください。</para>
<para>パッケージによっては、環境により動作や構築ができなくなるような、正しくない
libtoolの使い方をしているものがあります。ありがちな間違いは以下のようなもの
@@ -182,7 +217,8 @@
<listitem>
<para>ルーチンの初期化を適切に呼ばずにlibltdlを使う。関数lt_dlinit()を呼んで、
- マクロLTDL_SET_PRELOADED_SYMBOLSを実行形式にインクルードするようにしましょ
+ マクロ
+ <varname>LTDL_SET_PRELOADED_SYMBOLS</varname>を実行形式にインクルードするようにしましょ
う。</para>
</listitem>
</itemizedlist>
@@ -199,9 +235,9 @@
<filename>pkgsrc/mk/automake.mk</filename>で用
意されています。詳細は、このファイル中のコメントをご覧ください。</para>
- <para>autoconfのみを必要とするパッケージでは以下のようになります:</para>
+ <para>autoconfのみを必要とするパッケージでは以下のようになります: </para>
- <programlisting>AUTOCONF_REQD= 2.50 # if default version is not good enough
+ <programlisting>AUTOCONF_REQD= 2.50 # if default version is not good enough
...
pre-configure:
@@ -210,9 +246,7 @@
...
.include "../../mk/autoconf.mk"</programlisting>
-<para>
-また、automakeとautoconfを必要とするパッケージでは以下のようになります:
-</para>
+ <para> また、automakeとautoconfを必要とするパッケージでは以下のようになります: </para>
<programlisting>AUTOMAKE_REQD= 1.7.1 # if default version is not good enough
...
@@ -227,68 +261,138 @@
...
.include "../mk/automake.mk"</programlisting>
- <para>生成されたファイルに対して、configureプロセスがさらに変更を加える時がありま
+ <para> GNU Automake を使うパッケージは、ほぼ確実に
+ GNU Make を必要としますが、この依存関係は
+ <filename>mk/automake.mk</filename> で自動的に処理されます。 </para>
+
+ <para> 生成されたファイルに対して、configureプロセスがさらに変更を加える時がありま
すが、この時には構築プロセスが一連のautomakeの手順を再実行しようとします。
configureの段階でさまざまなファイルに手を加えると、この挙動は止められます。
この挙動が問題が起こす場合は、そのパッケージのMakefileで
- <varname>AUTOMAKE_OVERRIDE=NO</varname>を設定することができます。</para>
+ <varname>AUTOMAKE_OVERRIDE=NO</varname>を設定することができます。 </para>
</sect1>
<sect1>
<title>パッケージの設定ファイル</title>
-
- <para>パッケージの設定ファイルの場所は、<varname>${PKG_SYSCONFDIR}</varname>として指示され、この値は
+
+ <para> パッケージの設定ファイルの場所は、<varname>${PKG_SYSCONFDIR}</varname>として指示され、この値は
configureおよびbuildのプロセスに渡されます。
<varname>PKG_SYSCONFDIR</varname>は、他のmake変数
- のさまざまな設定によってカスタマイズすることができます:</para>
+ のさまざまな設定によってカスタマイズすることができます: </para>
<itemizedlist>
<listitem>
- <para><varname>PKG_SYSCONFBASE</varname>は主たる設定ディレクトリーで、パッケージ用の設定ファイルす
- べてがこれ以下に置かれます。デフォルトは<filename>${PREFIX}/etc</filename>ですが、
- <filename>/etc/mk.conf</filename>で上書きすることができます。</para>
+ <para> <varname>PKG_SYSCONFBASE</varname>は主たる設定ディレクトリーで、パッケージ用の設定ファイルす
+ べてがこれ以下に置かれます。デフォルトは<filename>${PREFIX}/etc</filename>ですが、
+ <filename>/etc/mk.conf</filename>で上書きすることができます。 </para>
</listitem>
<listitem>
- <para><varname>PKG_SYSCONFSUBDIR</varname>は
+ <para> <varname>PKG_SYSCONFSUBDIR</varname>は
<varname>PKG_SYSCONFBASE</varname>のサブディレクトリーで、個々のパッケー
ジ用の設定ファイルはこの下に置かれます。たとえば、Apacheの設定ファイルは
すべて、
<varname>${PKG_SYSCONFBASE}</varname>のサブディレクトリー
<filename>httpd/</filename>の下に置かれます。こ
- れは、パッケージのMakefileで設定することを想定しています。</para>
+ れは、パッケージのMakefileで設定することを想定しています。
+ </para>
</listitem>
<listitem>
- <para>デフォルトでは
- <varname>PKG_SYSCONFDIR=${PKG_SYSCONFBASE}/${PKG_SYSCONFSUBDIR}</varname>にな
- りますが、このデフォルト値は、個々のパッケージに対して
+ <para> デフォルトでは
+ <varname>PKG_SYSCONFDIR</varname> は
+ <varname>${PKG_SYSCONFBASE}/${PKG_SYSCONFSUBDIR}</varname> に設定されますが、
+ このデフォルト値は、個々のパッケージに対して
<varname>PKG_SYSCONFDIR.${PKG_SYSCONFVAR}</varname> を設定することで上書きすることができます。
この<varname>PKG_SYSCONFVAR</varname>
は、デフォルトでは<varname>${PKGBASE}</varname>です。これは、パッケージの
Makefileで設定するためのものではなく、ユーザーが個々のパッケージについて
- <varname>PKG_SYSCONFDIR</varname>の設定を特別な場所に上書きするために予約されているものです。</para>
+ <varname>PKG_SYSCONFDIR</varname>の設定を特別な場所に上書きするために予約されているものです。
+ </para>
+ </listitem>
+ </itemizedlist>
+
+ <para> ユーザーがカスタマイズすべき変数は、
+ <varname>PKG_SYSCONFBASE</varname>と <varname>PKG_SYSCONFDIR.${PKG_SYSCONFVAR}</varname>だけです。
+ 通常、ユーザーは
+ <varname>PKG_SYSCONFBASE</varname>を
+ <filename>/etc</filename>に設定するか、またはデフォルトの場所の
+ <filename>${PREFIX}/etc</filename>のままにするでしょう。 </para>
+ </sect1>
+
+ <sect1>
+ <title>ユーザーとの対話</title>
+
+ <para>時々、パッケージがユーザーとの対話を必要とする場合がありますが、そのような
+ 状況は何通りもありえます:</para>
+
+ <itemizedlist>
+ <listitem>
+ <para>distfileの取得に関する補助</para>
+ </listitem>
+
+ <listitem>
+ <para>パッケージの構築前の設定の補助</para>
+ </listitem>
+
+ <listitem>
+ <para>構築過程の最中の補助</para>
+ </listitem>
+
+ <listitem>
+ <para>パッケージのインストール中の補助</para>
</listitem>
</itemizedlist>
- <para>ユーザーがカスタマイズすべき変数は、
- <varname>PKG_SYSCONFBASE</varname>と
- <varname>PKG_SYSCONFDIR.${PKG_SYSCONFVAR}</varname>だけです。通常、ユーザーは
- <varname>PKG_SYSCONFBASE</varname>を
- <filename>/etc</filename>に設定するか、またはデフォルトの場所の
- <filename>${PREFIX}/etc</filename>のままにするでしょう。</para>
+ <para>どの段階で対話が必要になるかをpkgsrcの機構に知らせるため、<varname>INTERACTIVE_STAGE</varname>
+ 定義が用意されており、パッケージの<filename>Makefile</filename>で定義します。たとえば以下のよう
+ にします。</para>
+
+ <programlisting>INTERACTIVE_STAGE= build</programlisting>
+
+ <para>複数の段階を指定することもできます:</para>
+
+ <programlisting>INTERACTIVE_STAGE= configure install</programlisting>
</sect1>
<sect1>
- <title>作者へのフィードバック</title>
+ <title>パッケージの移植性</title>
- <para>もしパッケージの不具合を発見し動作するように修正した場合、&os;上で動作さ
+ <para>pkgsrc の目玉の一つは、多くのプラットフォームで動作することです。
+ そのため、pkgsrc のパッケージの移植性をできるかぎり高めることが重要になります。
+ pkgsrc の作業に際して、
+ 具体的には以下のような事項に注意してください。</para>
+
+ <sect2>
+ <title>${INSTALL}, ${INSTALL_DATA_DIR}, ...</title>
+
+ <para>一部のプラットフォームに附属する BSD 互換の <command>install</command> は、
+ 一度に複数の操作をおこなうことができません。
+ このため、 <quote>${INSTALL}</quote> などを使うときは、以下のようにします。</para>
+
+ <programlisting>${INSTALL_DATA_DIR} ${PREFIX}/dir1
+${INSTALL_DATA_DIR} ${PREFIX}/dir2</programlisting>
+ </sect2>
+
+<!--
+ <sect2>
+XXX more portability stuff
+XXX USE_PKGLOCALEDIR
+XXX ???
+ </sect2>
+-->
+ </sect1>
+
+ <sect1>
+ <title>作者へのフィードバック</title>
+
+ <para> もしパッケージの不具合を発見し動作するように修正した場合、NetBSD上で動作さ
せるために特別な手順が必要だった場合、あるいはさまざまなソフトウェアの拡張
をおこなった場合、これらの修正をプログラムのオリジナルの作者へ報告してくだ
さい。このようなサポートによって、プログラムの次のリリースにそれらの修正を
- 反映することができます。そして、&os;パッケージシステムを使用していない人々
- も、あなたの努力のおかげで幸せになれます。</para>
+ 反映することができます。そして、NetBSDパッケージシステムを使用していない人々
+ も、あなたの努力のおかげで幸せになれます。 </para>
- <para>フリーソフトウェアの理念をサポートして下さい。</para>
+ <para> フリーソフトウェアの理念をサポートして下さい。 </para>
</sect1>
</chapter>
Index: Documentation/pkgsrc/fixes.xml
===================================================================
RCS file: /cvsroot/htdocs/Documentation/pkgsrc/Attic/fixes.xml,v
retrieving revision 1.1
retrieving revision 1.4
diff -u -r1.1 -r1.4
--- Documentation/pkgsrc/fixes.xml 6 Jun 2004 13:31:54 -0000 1.1
+++ Documentation/pkgsrc/fixes.xml 29 Sep 2004 13:08:36 -0000 1.4
@@ -1,23 +1,27 @@
-<!-- $NetBSD: fixes.xml,v 1.1 2004/06/06 13:31:54 grant Exp $ -->
+<!-- $NetBSD: fixes.xml,v 1.4 2004/09/29 13:08:36 hubertf Exp $ -->
-<chapter id="fixes">
+<chapter id="fixes"> <?dbhtml filename="fixes.html"?>
<title>Notes on fixes for packages</title>
<sect1>
<title>CPP defines</title>
-
- <para>To port an application to &os;, it's usually necessary for the
+
+ <para>
+ To port an application to NetBSD, it's usually necessary for the
compiler to be able to judge the system on which it's compiling, and
- we use definitions so that the C pre-processor can do this.</para>
+ we use definitions so that the C pre-processor can do this.
+ </para>
- <para>To test whether you are working on a 4.4 BSD-derived system, you
+ <para>
+ To test whether you are working on a 4.4 BSD-derived system, you
should use the BSD definition, which is defined in
- <filename><sys/param.h></filename> on said systems.</para>
+ <filename><sys/param.h></filename> on said systems.
+ </para>
<programlisting><![CDATA[#include <sys/param.h>]]></programlisting>
- <para>and then you can surround the BSD-specific parts of your port using
- the conditional:</para>
+ <para>and then you can surround the BSD-specific parts of your
+ package's C/C++ code using this conditional:</para>
<programlisting><![CDATA[#if (defined(BSD) && BSD >= 199306)
...
@@ -26,7 +30,7 @@
<para>Please use the <quote>__NetBSD__</quote> definition sparingly - it
should only apply to features of &os; that are not present in other
4.4-lite derived BSDs.</para>
- </sect1>
+</sect1>
<sect1 id="fixes.libtool">
<title>Shared libraries - libtool</title>
@@ -60,7 +64,7 @@
<listitem>
<para>For the linking of the library, remove any <quote>ar</quote>,
<quote>ranlib</quote>, and <quote>ld -Bshareable</quote> commands,
- and use instead:</para>
+ and instead use:</para>
<programlisting>${LIBTOOL} --mode=link ${CC} -o ${.TARGET:.a=.la} ${OBJS:.o=.lo} -rpath ${PREFIX}/lib -version-info major:minor</programlisting>
@@ -74,6 +78,26 @@
and minor are zero, as libtool will otherwise strip off the
shared library version.</para>
+ <para> From the libtool manual:</para>
+
+ <programlisting>
+ So, libtool library versions are described by three integers:
+
+CURRENT
+ The most recent interface number that this library implements.
+
+REVISION
+ The implementation number of the CURRENT interface.
+
+AGE
+ The difference between the newest and oldest interfaces that this
+ library implements. In other words, the library implements all the
+ interface numbers in the range from number `CURRENT - AGE' to
+ `CURRENT'.
+
+ If two libraries have identical CURRENT and AGE numbers, then the
+dynamic linker chooses the library with the greater REVISION number. </programlisting>
+
<para>The <quote>-release</quote> option will produce different results for
a.out and ELF (excluding symlinks) in only one case. An ELF library of
the form
@@ -99,7 +123,7 @@
use <quote>-module -avoid-version</quote> to prevent them
getting version tacked on.</para>
- <para><filename>PLIST</filename> gets the <filename>foo.so</filename>
+ <para>The <filename>PLIST</filename> file gets the <filename>foo.so</filename>
entry.</para>
</listitem>
@@ -114,9 +138,7 @@
because it expects you to change that argument to be the
<filename>.la</filename> file. e.g.</para>
- <informalexample>
- <programlisting>${LIBTOOL} --mode=link ${CC} -o someprog -L../somelib -lsomelib</programlisting>
- </informalexample>
+ <programlisting>${LIBTOOL} --mode=link ${CC} -o someprog -L../somelib -lsomelib</programlisting>
<para>should be changed to:</para>
@@ -131,35 +153,47 @@
<quote>${LIBTOOL} --mode=install</quote>, and change the library
name to <filename>.la</filename>. e.g.</para>
- <informalexample>
- <programlisting>${LIBTOOL} --mode=install ${BSD_INSTALL_DATA} ${SOMELIB:.a=.la} ${PREFIX}/lib</programlisting>
- </informalexample>
+ <programlisting>${LIBTOOL} --mode=install ${BSD_INSTALL_DATA} ${SOMELIB:.a=.la} ${PREFIX}/lib</programlisting>
<para>This will install the static <filename>.a</filename>, shared
library, any needed symlinks, and run &man.ldconfig.8;.</para>
</listitem>
+
+ <listitem>
+ <para> In your <filename>PLIST</filename>, include all of the
+ <filename>.a</filename>, <filename>.la</filename>, and
+ <filename>.so</filename>, <filename>.so.CURRENT</filename>
+ and <filename>.so.CURRENT.REVISION</filename> files
+ (this is a change from the previous behaviour). </para>
+ </listitem>
+
</orderedlist>
</sect1>
<sect1>
<title>Using libtool on GNU packages that already support libtool</title>
- <para>Add <varname>USE_LIBTOOL=yes</varname> and
- <varname>LTCONFIG_OVERRIDE=${WRKSRC}/ltconfig</varname> to the
- package Makefile as the quick way to bypass the pkg's own
- <emphasis>libtool</emphasis>. The pkg's own
- <emphasis>libtool</emphasis> is created by ltconfig script at
- do-configure target. If <varname>USE_LIBTOOL</varname> and
- <varname>LTCONFIG_OVERRIDE</varname> are defined, the specified
- ltconfig is overridden, using <pkg>devel/libtool</pkg> instead of
- the pkg's own libtool. For newer versions of libtool (without
- ltconfig) it may be necessary to use
- <varname>LIBTOOL_OVERRIDE=${WRKSRC}/libtool</varname> instead.</para>
+ <para>Add <varname>USE_LIBTOOL=yes</varname> to the
+ package Makefile. This will override the package's own libtool
+ in most cases. For older libtool using packages, libtool is
+ made by ltconfig script during the do-configure step; you can
+ check the libtool script location by doing <command>make
+ configure; find work*/ -name libtool</command>. </para>
+
+ <para> <varname>LIBTOOL_OVERRIDE</varname> specifies which libtool
+ scripts, relative to <varname>WRKSRC</varname>, to override. By
+ default, it is set to <quote>libtool */libtool
+ */*/libtool</quote>. If this does not match the location of the
+ package's libtool script(s), set it as appropriate. </para>
+
+ <para> If you do not need <filename>*.a</filename> static
+ libraries built and installed, then use
+ <varname>SHLIBTOOL_OVERRIDE</varname> instead. </para>
<para>If your package makes use of the platform independent library
for loading dynamic shared objects, that comes with libtool
- (libltdl), you should include the libtool buildlink2.mk (and
- set <varname>USE_BUILDLINK2=YES</varname>).</para>
+ (libltdl), you should include the libtool buildlink3.mk (and
+ set <varname>USE_BUILDLINK3=YES</varname>).</para>
<para>Some packages use libtool incorrectly so that the package may not work or
build in some circumstances. Some of the more common errors are:</para>
@@ -186,7 +220,8 @@
<listitem>
<para>The use of libltdl without the correct calls to initialisation routines.
The function lt_dlinit() should be called and the macro
- LTDL_SET_PRELOADED_SYMBOLS included in executables.</para>
+ <varname>LTDL_SET_PRELOADED_SYMBOLS</varname> included in
+ executables.</para>
</listitem>
</itemizedlist>
</sect1>
@@ -203,9 +238,9 @@
dealing with these tools. See comments in these files for
details.</para>
- <para>For packages that need only autoconf:</para>
+ <para> For packages that need only autoconf: </para>
- <programlisting>AUTOCONF_REQD= 2.50 # if default version is not good enough
+ <programlisting>AUTOCONF_REQD= 2.50 # if default version is not good enough
...
pre-configure:
@@ -214,9 +249,7 @@
...
.include "../../mk/autoconf.mk"</programlisting>
-<para>
-and for packages that need automake and autoconf:
-</para>
+ <para> and for packages that need automake and autoconf: </para>
<programlisting>AUTOMAKE_REQD= 1.7.1 # if default version is not good enough
...
@@ -231,75 +264,145 @@
...
.include "../mk/automake.mk"</programlisting>
- <para>There are times when the configure process makes additional
- changes to the generated files, which then causes the build
- process to try to re-execute the automake sequence. This is
- prevented by touching various files in the configure stage. If
- this causes problems with your package you can set
- <varname>AUTOMAKE_OVERRIDE=NO</varname> in the package
- Makefile.</para>
+ <para> Packages which use GNU Automake will almost certainly
+ require GNU Make, but that's automatically provided for you in
+ <filename>mk/automake.mk</filename>. </para>
+
+ <para> There are times when the configure process makes
+ additional changes to the generated files, which then causes
+ the build process to try to re-execute the automake sequence.
+ This is prevented by touching various files in the configure
+ stage. If this causes problems with your package you can set
+ <varname>AUTOMAKE_OVERRIDE=NO</varname> in the package
+ Makefile. </para>
</sect1>
<sect1>
<title>Package configuration files</title>
-
- <para>Packages should be taught to look for their configuration
+
+ <para> Packages should be taught to look for their configuration
files in <varname>${PKG_SYSCONFDIR}</varname>, which is passed
through to the configure and build processes.
<varname>PKG_SYSCONFDIR</varname> may be customized in various
- ways by setting other make variables:</para>
+ ways by setting other make variables: </para>
<itemizedlist>
<listitem>
- <para><varname>PKG_SYSCONFBASE</varname> is the main config directory
- under which all package configuration files are to be found.
- This defaults to <filename>${PREFIX}/etc</filename>, but may
- be overridden in <filename>/etc/mk.conf</filename>.</para>
+ <para> <varname>PKG_SYSCONFBASE</varname> is the main config
+ directory under which all package configuration files are
+ to be found. This defaults to
+ <filename>${PREFIX}/etc</filename>, but may be overridden
+ in <filename>/etc/mk.conf</filename>.</para>
</listitem>
<listitem>
- <para><varname>PKG_SYSCONFSUBDIR</varname> is the subdirectory of
+ <para> <varname>PKG_SYSCONFSUBDIR</varname> is the subdirectory of
<varname>PKG_SYSCONFBASE</varname> under which the
configuration files for a particular package may be found, e.g.
the Apache configuration files may all be found under the
<filename>httpd/</filename> subdirectory of
<varname>${PKG_SYSCONFBASE}</varname>. This should be set in
- the package Makefile.</para>
+ the package Makefile.
+ </para>
</listitem>
- <listitem>
- <para>By default,
- <varname>PKG_SYSCONFDIR=${PKG_SYSCONFBASE}/${PKG_SYSCONFSUBDIR}</varname>,
+ <listitem>
+ <para> By default,
+ <varname>PKG_SYSCONFDIR</varname> is set to
+ <varname>${PKG_SYSCONFBASE}/${PKG_SYSCONFSUBDIR}</varname>,
but this may be overridden by setting
<varname>PKG_SYSCONFDIR.${PKG_SYSCONFVAR}</varname> for a
particular package, where <varname>PKG_SYSCONFVAR</varname>
defaults to <varname>${PKGBASE}</varname>. This is not meant to
be set by a package Makefile, but is reserved for users who wish
to override the <varname>PKG_SYSCONFDIR</varname> setting for
- a particular package with a special location.</para>
+ a particular package with a special location.
+ </para>
+ </listitem>
+ </itemizedlist>
+
+ <para> The only variables that users should customize are
+ <varname>PKG_SYSCONFBASE</varname> and <varname>PKG_SYSCONFDIR.${PKG_SYSCONFVAR}</varname>.
+ Users will typically want to set
+ <varname>PKG_SYSCONFBASE</varname> to
+ <filename>/etc</filename>, or to accept the default location
+ of <filename>${PREFIX}/etc</filename>. </para>
+ </sect1>
+
+ <sect1>
+ <title>User Interaction</title>
+
+ <para>Occasionally, packages require interaction from the user, and this can be
+ in a number of ways:</para>
+
+ <itemizedlist>
+ <listitem>
+ <para>help in fetching the distfiles</para>
+ </listitem>
+
+ <listitem>
+ <para>help to configure the package before it is built</para>
+ </listitem>
+
+ <listitem>
+ <para>help during the build process</para>
+ </listitem>
+
+ <listitem>
+ <para>help during the installation of a package</para>
</listitem>
</itemizedlist>
- <para>The only variables that users should customize are
- <varname>PKG_SYSCONFBASE</varname> and
- <varname>PKG_SYSCONFDIR.${PKG_SYSCONFVAR}</varname>.
- Users will typically want to set
- <varname>PKG_SYSCONFBASE</varname> to
- <filename>/etc</filename>, or to accept the default location
- of <filename>${PREFIX}/etc</filename>.</para>
+ <para>The <varname>INTERACTIVE_STAGE</varname> definition is provided to notify
+ the pkgsrc mechanism of an interactive stage which will be needed, and
+ this should be set in the package's <filename>Makefile</filename>. e.g.</para>
+
+ <programlisting>INTERACTIVE_STAGE= build</programlisting>
+
+ <para>Multiple interactive stages can be specified:</para>
+
+ <programlisting>INTERACTIVE_STAGE= configure install</programlisting>
</sect1>
<sect1>
- <title>Feedback to the author</title>
+ <title>Portability of packages</title>
- <para>If you have found any bugs in the package you make available,
- if you had to do special steps to make it run under &os; or
+ <para>One appealing feature of pkgsrc is that it runs on many different
+ platforms. As a result, it is important to ensure, where possible,
+ that packages in pkgsrc are portable. There are some particular
+ details you should pay attention to while working on pkgsrc.</para>
+
+ <sect2>
+ <title>${INSTALL}, ${INSTALL_DATA_DIR}, ...</title>
+
+ <para>The BSD-compatible <command>install</command> supplied with some
+ operating systems will not perform more than one operation at a time.
+ As such, you should call <quote>${INSTALL}</quote>, etc. like this:</para>
+
+ <programlisting>${INSTALL_DATA_DIR} ${PREFIX}/dir1
+${INSTALL_DATA_DIR} ${PREFIX}/dir2</programlisting>
+ </sect2>
+
+<!--
+ <sect2>
+XXX more portability stuff
+XXX USE_PKGLOCALEDIR
+XXX ???
+ </sect2>
+-->
+ </sect1>
+
+ <sect1>
+ <title>Feedback to the author</title>
+
+ <para> If you have found any bugs in the package you make available,
+ if you had to do special steps to make it run under NetBSD or
if you enhanced the software in various other ways, be sure
to report these changes back to the original author of the
program! With that kind of support, the next release of the
program can incorporate these fixes, and people not using the
- &os; packages system can win from your efforts.</para>
+ NetBSD packages system can win from your efforts. </para>
- <para>Support the idea of free software!</para>
+ <para> Support the idea of free software! </para>
</sect1>
</chapter>