Chapter 17. 構築の手順

本章では、パッケージがどのように構築されるかについて、詳しく説明します。パッケージの構築は、複数の相 (phase) (たとえば、fetch, build, install) にわかれており、そのすべてを以下の各節で説明します。それぞれの段階は、pre-, do-, post- のいずれかが相名の前についた、いわゆる期 (stage) にわかれます。(たとえば、 pre-configure, post-build などです。) 実際に何かがおこなわれるのは、ほとんどが do-* 期においてです。

標準的なターゲット (fetch など) は、決して上書きしないでください。変更する必要がある場合は、対応する do-* ターゲットを上書きしてください。

プログラムを構築するための基本的な手順は常に同じです。最初に、プログラムのソースファイル(distfile)をローカルシステムへ持ってきて展開します。コンパイルするための pkgsrc 独自のパッチを適用した後に、ソフトウェアを設定し、構築(通常、コンパイルすることによって)します。最後に作成されたバイナリー等を、システムにインストールします。

それぞれの段階で何が起きているかを、もっと詳しく把握するために、 PKG_VERBOSE 変数を設定することができます。または、patch の段階における詳細に関心があるだけなら、 PATCH_DEBUG 変数を設定することもできます。

17.2. プログラムの場所

次のセクションでNetBSDパッケージシステムによって実行される手順の概略を述べる前に、プログラムがインストールされる場所、その場所に影響をおよぼす変数について簡単に記述します。

自動変数PREFIXは、最終的にプログラムのすべてのファイルがインストールされる場所をしめします。通常、LOCALBASE (/usr/pkg)、またはcrossカテゴリーのパッケージのためのCROSSBASEと同じ場所になっています。 PREFIXの値は、プログラムのソース中でこれらのファイルが符号化されるさまざまな場所に使用されるべきです。詳細に関しては、Section 11.3, “patches/*”およびSection 19.3.1, “共有ライブラリー - libtool”を参照して下さい。

これらの変数のどれかを選択し使用する場合には、以下のルールに従ってください。

PREFIXは常に現在のパッケージがインストールされる場所を指します。パッケージ自身のインストール先のパスを参照する時に、“${PREFIX}”を使用してください。
LOCALBASEは、すべての非X11パッケージがインストールされる場所です。他の非X11パッケージによってインストールされたインクルードファイルやライブラリーの場所をさがすためのコンパイラーの-Iや-Lオプションを指定する場合に、 “${LOCALBASE}”を使用してください。 LOCALBASE という変数名は、FreeBSD でパッケージをすべて /usr/local にインストールしていたことに由来します。 pkgsrc では /usr/local をシステム管理者のために使わないようにしているので、この変数名は間違った名前です。
X11BASEは、実際に(xsrcなどに由来する)X11ディストリビューションがインストールされる場所です。 通常のX11のインクルードファイル(パッケージとしてインストールされていない)をさがす場合、“${X11BASE}”を使用してください。
X11 ベースのパッケージは特別です。インストールされる場所は、 X11BASE と LOCALBASE のどちらに依存することもありえます。

通常、X11 のパッケージは、できるかぎり LOCALBASE にインストールするものです。X11 のパッケージでは、X11 が必要なことを要求し、適切な編集フラグを持つようにするために、 ../../mk/x11.buildlink3.mk をインクルードする必要があります。

しかし、LOCALBASE 以下にはインストールできないパッケージもあります。 app-defaults ファイルが附属するようなパッケージが該当します。このようなパッケージは例外であり、X11BASE 以下にインストールする必要があります。そうするためには、パッケージ側で USE_X11BASE または USE_IMAKE のいずれかを設定します。

註: Makefile で USE_IMAKE や USE_X11BASE を定義したパッケージによってインストールされたインクルードファイルやライブラリーをさがす場合、 ${X11BASE} と ${LOCALBASE} を両方調べる必要があります。 X11 パッケージをすべて強制的に LOCALBASE にインストールさせるために、 pkgtools/xpkgwedge パッケージが標準で有効になっています。
X11パッケージのインストール場所を参照する用途には、X11PREFIXを使ってください。X11PREFIXは、xpkgwedgeがインストールされていない場合は X11BASEとなり、xpkgwedgeがインストールされている場合はLOCALBASEとなります。
xpkgwedgeがインストールされている場合、パッケージによってインストール先がX11BASEになっていたりLOCALBASEになっていたりすることがあります。インストールされているパッケージのprefixを決めるために、EVAL_PREFIX定義を使うことができます。この定義に“DIRNAME=<package>”の形式の組を書くと、make(1)変数DIRNAMEが、インストールされているパッケージ <package>のprefixに設定されます。そのパッケージがインストールされていない場合は“${X11PREFIX}”に設定されます。

例を使って説明するのが一番いいでしょう。

以下は、 pkgsrc/wm/scwm/Makefileからの抜粋です。
```
EVAL_PREFIX+=           GTKDIR=gtk+
CONFIGURE_ARGS+=        --with-guile-prefix=${LOCALBASE:Q}
CONFIGURE_ARGS+=        --with-gtk-prefix=${GTKDIR:Q}
CONFIGURE_ARGS+=        --enable-multibyte
```
EVAL_PREFIXを使って評価するパッケージに対して、以下のような定義を使ってデフォルトを定義することができます。
```
GTKDIR_DEFAULT= ${LOCALBASE}
```
ここでGTKDIRは、 EVAL_PREFIX での最初の定義の組に対応します。
パッケージは ${PREFIX} 以下に、 hier(7) に準じてファイルをインストールするようにします。ただしマニュアルページは例外で、${PREFIX}/share/man ではなく ${PREFIX}/man にインストールします。

17.3. 構築の過程で使われるディレクトリー

パッケージの構築時には、ソースファイル、一時ファイル、 pkgsrc 内部ファイルなどを置いておくために、さまざまなディレクトリーが使われます。そのようなディレクトリーについて説明します。

ディレクトリーを指す変数のなかには、相対パス名を値に持つものがあります。このような相対パス名の基点となるディレクトリーは、おもに二つあります。一つは PKGSRCDIR/PKGPATH で、pkgsrc 特有のディレクトリー用です。もう一つは WRKSRC で、パッケージそのものの内部にあるディレクトリー用です。

PKGSRCDIR: 絶対パス名で、 pkgsrc のルートディレクトリーを指します。通常は、この変数を使う必要はありません。
PKGDIR: 当該パッケージを指す絶対パス名です。
PKGPATH: PKGSRCDIR を基点とした相対パス名で、当該パッケージを指します。
WRKDIR: 絶対パス名で、全作業がおこなわれるディレクトリーを指します。 distfile はこのディレクトリーに展開されます。一般的に、このディレクトリーには、 buildlink や wrappers など、 pkgsrc の各種基盤が使う一時ディレクトリーも含まれます。
WRKSRC: 絶対パス名で、distfile が展開されるディレクトリーを指します。普通は、WRKDIR 直下のサブディレクトリーであり、多くの場合は、このディレクトリーにおける、唯一の隠されていないディレクトリーエントリーです。この変数は、パッケージの Makefile で変更することができます。

CREATE_WRKDIR_SYMLINK 定義は、 yes または no のいずれかの値をとり、標準状態では no になります。これは、 pkgsrc の個々のパッケージのディレクトリー内に、 WRKDIR へのシンボリックリンクを作成するか否かを示します。 pkgsrc ツリーを読み取り専用として使いたい場合は、 CREATE_WRKDIR_SYMLINK の値を no にしてください。

17.4. 相の実行

make phase (phase は相の名前) と打てば、その相を実行することができます。こうすると、その相のために必要な相をすべて自動的に実行します。相を指定しない場合は build 相になります。つまり、あるパッケージのディレクトリーで、引数なしで make を実行すると、パッケージが構築されますが、インストールはされません。

17.5. fetch 相

パッケージの構築の最初の段階は、配布ファイル (distfiles) を、そのファイルを配布しているサイトから取得することです。これは fetch 相がおこなう仕事です。

17.5.1. 何を、どこから取得するか

単純な場合では、MASTER_SITES で distfile (distfile のファイル名は DISTNAME が使われます) を取得する URL をすべて定義します。これより複雑な場合については、以下で説明します。

変数 DISTFILES は、取得する必要のある distfile を並べたリストを指定します。この値は、標準では ${DISTNAME}${EXTRACT_SUFX} になり、ほとんどのパッケージではあえて定義する必要がありません。 EXTRACT_SUFX は、標準では .tar.gz になりますが、自由に変更することができます。なお、標準で定義される distfile に加えて別の distfile が必要な場合は、それを += 演算子を使って追加することはできません。たとえば以下のように書く必要があります。

DISTFILES=      ${DISTNAME}${EXTRACT_SUFX} additional-files.tar.gz

各 distfile は、通常は MASTER_SITES に並べられたサイトから取得されます。パッケージに複数の DISTFILES または複数の PATCHFILES があり、それらが異なるサイトで配布されている場合は、 distfile ファイル (サフィックスを含む) の配布場所の URL を並べたリストを SITES.distfile に設定することができます。

DISTFILES=      ${DISTNAME}${EXTRACT_SUFX}
DISTFILES+=     foo-file.tar.gz
SITES.foo-file.tar.gz= \
http://www.somewhere.com/somehow/ \
http://www.somewhereelse.com/mirror/somehow/

distfile を実際に取得する際、それらは、 MASTER_SITES または SITES.* に各 distfile のファイル名をそのまま (間にスラッシュを入れずに) つなげた形の URL から取得されます。このため、サイトを定義する変数の値は、スラッシュその他の分離記号で終わる必要があります。このため、たとえば MASTER_SITES を、distfile 名を引数としてとる CGI スクリプトの URL にすることができます。そうした場合、以下のような形で定義することになります。

MASTER_SITES=   http://www.example.com/download.cgi?file=

例外は、URL の前にダッシュ (-) がついている場合です。この場合、その URL を (distfile とつなげずに) そのまま使って distfile を取得し、取得したファイルを distfile の名前で保存します。

パッケージで使うため、MASTER_SITES 用にあらかじめ定義された値がいくつか用意されています。各変数の意味は、名前から明らかでしょう。

${MASTER_SITE_APACHE}
${MASTER_SITE_BACKUP}
${MASTER_SITE_CYGWIN}
${MASTER_SITE_DEBIAN}
${MASTER_SITE_FREEBSD}
${MASTER_SITE_FREEBSD_LOCAL}
${MASTER_SITE_GENTOO}
${MASTER_SITE_GNOME}
${MASTER_SITE_GNU}
${MASTER_SITE_GNUSTEP}
${MASTER_SITE_IFARCHIVE}
${MASTER_SITE_KDE}
${MASTER_SITE_MOZILLA}
${MASTER_SITE_MYSQL}
${MASTER_SITE_OPENOFFICE}
${MASTER_SITE_PERL_CPAN}
${MASTER_SITE_PGSQL}
${MASTER_SITE_R_CRAN}
${MASTER_SITE_SOURCEFORGE}
${MASTER_SITE_SOURCEFORGE_JP}
${MASTER_SITE_SUNSITE}
${MASTER_SITE_SUSE}
${MASTER_SITE_TEX_CTAN}
${MASTER_SITE_XCONTRIB}
${MASTER_SITE_XEMACS}

名前から意味がわかりにくいものについて、説明しておきます。 MASTER_SITE_BACKUP には、ftp://ftp.NetBSD.org/pub/pkgsrc/distfiles/${DIST_SUBDIR} で保守されている、パッケージのバックアップサイトが含まれます。 MASTER_SITE_LOCAL には、ftp://ftp.NetBSD.org/pub/pkgsrc/distfiles/LOCAL_PORTS/ で保守されている、パッケージのローカルなソース配布物が含まれます。

もしこれらの予め定義されたサイトの1つを選んだ場合、そのサイトのサブディレクトリーを指定することが必要となるかもしれません。これらのマクロは複数の実際のサイトに展開されるかもしれませんので、サブディレクトリーを指定する場合は、以下の表記を使わなければなりません:

MASTER_SITES=   ${MASTER_SITE_GNU:=subdirectory/name/}
MASTER_SITES=   ${MASTER_SITE_SOURCEFORGE:=project_name/}

サブディレクトリー名の後のスラッシュ/に注意してください。

17.5.2. ファイルの取得はどのようにおこなわれるか?

fetch 相では、distfile がすべてローカルディレクトリー (DISTDIR, pkgsrc 利用者が設定可能) に存在する状態にします。 distfile は以下の形式のコマンドを使って取得されます。

${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site}${file} ${FETCH_AFTER_ARGS}

この ${site} には、複数の候補が決まった順序で使われます: 最初に MASTER_SITE_OVERRIDEを試み、次に、SITES.fileが定義されていればそれを、定義されていなければ、MASTER_SITESかPATCH_SITESのどちらかを試みます。そして、最後にMASTER_SITE_BACKUPの値を試みます。これらのうち最初のものと最後のもの以外の順序は、 MASTER_SORT_RANDOM を設定し、かつ MASTER_SORT_AWKか MASTER_SORT_REGEXを設定して、ユーザーが入れ換えることができます。

この取得用のコマンドと引数は、 FETCH_USING 変数に応じたものが使われます。上述の例は、FETCH_USING=custom とした場合のものです。

the NetBSD Foundation が運営している distfile のミラーサイトでは、自由に配布可能な distfile をミラーするために mirror-distfiles ターゲットを使っています。NO_SRC_ON_FTP を (たいていは “${RESTRICTED}” に) 設定しているパッケージの distfile はミラーされません。

17.6. checksum 相

distfileを取得した後に、チェックサムを生成し、distinfoファイルに保存されたチェックサムと比較します。もし、チェックサムが一致しなければ、構築は中断されます。これはパッケージ作成時と同じdistfileが、構築に使用されていること、つまり、悪意や一次配布サイトでの意図的な差し替えやネットワークの損失によってdistfileが変更されていないことを保証するためです。

17.7. extract 相

distfileがローカルシステム上に存在している場合、通常、それらは圧縮アーカイブフォーマットで保存されているので、展開する必要があります。

標準では、DISTFILES はすべて展開されます。一部だけを展開する必要がある場合は、 EXTRACT_ONLY 変数を、展開する必要のあるファイルを並べたリストに設定することができます。

通常、ファイルの展開は mk/extract/extract という小さなプログラムを使っておこなわれます。このプログラムは、各種アーカイブ形式の展開方法を知っているので、何も変更する必要はないでしょう。それでも変更が必要な場合は、以下の変数を使うとよいでしょう。

EXTRACT_OPTS_{BIN,LHA,PAX,RAR,TAR,ZIP,ZOO}: この各変数を使って、展開用のコマンドのオプションを、標準のもの (mk/extract/extract で定義されています) から上書きします。
EXTRACT_USING: この変数は、tar アーカイブ展開用のコマンドを設定するもので、 bsdtar, gtar, nbtar (標準状態での値), pax または、コマンドの絶対パス名に設定することができます。 NetBSD の (tar として使われる) pax でうまく展開できない場合は、なるべく gtar より bsdtar を選ぶようにします。

必要なことが extract プログラムではできない場合は、ファイル展開用のコマンドを保持する EXTRACT_CMD 変数を上書きすることもできます。この変数で指定された展開用コマンドは、 ${WRKSRC} ディレクトリー内で実行されます。このコマンドの実行中は、シェル変数 extract_file に、展開中のアーカイブファイルの絶対パス名が保持されます。

これでもなお不十分な場合は、パッケージの Makefile で、 do-extract ターゲットを上書きすることができます。

17.8. patch 相

展開の後で、PATCHFILESで指定されたパッチとパッケージのpatchesサブディレクトリーに存在するパッチ、さらに、$LOCALPATCHES/$PKGPATH (たとえば /usr/local/patches/graphics/png)に存在するパッチのすべてが適用されます。 .Z、あるいは.gzで終る名前のパッチファイルは、適用する前に伸張されます。 .orig、.rejで終るものは無視されます。patch(1)のためのいくつかのオプションは、PATCH_DIST_ARGSで指定する事ができます。詳細に関してはSection 11.3, “patches/*”を参照して下さい。

デフォルトでは、パッチに曖昧さがあった場合にはpatch(1)が異常終了するような特別な引数が渡されます。パッチを修正(再作成)して、きれいに適用できるようにしてください。そうする理由は、曖昧さがあるパッチが一見うまく適用できても、実は誤った場所に適用されていて、深刻な問題を起こす可能性があるからです。

17.9. tools 相

この相についてはChapter 18, 構築や実行のために必要なツール で説明しています。

17.10. wrapper 相

この相では、コンパイラーとリンカー用のラッパープログラムが作成されます。以下の変数を使って、ラッパーに手を加えることができます。

ECHO_WRAPPER_MSG: 経過を表示するためのコマンドです。標準状態では何もしません。経過を見るには、この変数を ${ECHO} に設定します。
WRAPPER_DEBUG: この変数は、ラッパーのログファイルにより詳しい情報が必要かどうかに応じて、 yes (標準状態の値) または no に設定することができます。
WRAPPER_UPDATE_CACHE: この変数は、ラッパーの速度を改善するためキャッシュを使わせるかどうかに応じて、 yes または no に設定することができます。標準状態の値は yes ですが、キャッシュに対応していないプラットフォームでは強制的に no になります。
WRAPPER_REORDER_CMDS: 順序の並び替え用のコマンドを並べたリストです。並び替え用のコマンドは、 reorder:l:lib1:lib2 のような形式をしています。これを使うと -llib1 が常に -llib2 より先に現れるようになります。
WRAPPER_TRANSFORM_CMDS: 変換用のコマンドを並べたリストです。 [TODO: investigate further]

17.11. configure 相

ほとんどのソフトウェアは、実行対象のプラットフォームで利用できるヘッダーファイル、システムコール、およびライブラリールーチンについての情報を必要とします。この情報の判断はコンフィギュレーションとして知られているプロセスであり、通常、自動化されています。大抵の場合、スクリプトが配布物と一緒に提供され、それを実行することによりヘッダーファイルやMakefile等が生成されます。

パッケージが configure スクリプトを含んでいる場合、HAS_CONFIGURE を “yes” に設定することにより、実行することができます。もし、その configure スクリプトが GNU の autoconf スクリプトである場合は、かわりに、GNU_CONFIGURE を “yes” に指定してください。大雑把にいうと、configure 相では以下のようなことをしています。

.for d in ${CONFIGURE_DIRS}
        cd ${WRKSRC} \
        && cd ${d} \
        && env ${CONFIGURE_ENV} ${CONFIGURE_SCRIPT} ${CONFIGURE_ARGS}
.endfor

CONFIGURE_DIRS (標準では “.”) は、 WRKSRC からの相対位置でのパス名を並べたリストです。この各ディレクトリー内で、環境変数 CONFIGURE_ENV および引数 CONFIGURE_ARGS を使って configure スクリプトが実行されます。 CONFIGURE_ENV, CONFIGURE_SCRIPT (標準では “./configure”), CONFIGURE_ARGS の各変数は、いずれもパッケージ側で変更することができます。

もし、プログラムがコンフィギュレーションのために Imakefile を使用するのであれば、USE_IMAKE を “yes” に設定することにより、適切な手順が実行されます。 (もし、${X11PREFIX} にインストールされるパッケージが欲しいだけで、xmkmfを実行したくない場合、かわりにUSE_X11BASEを使用してください。) SCRIPTS_ENV に変数を設定すると、その変数を xmkmf の環境変数に追加することができます。

プログラムがコンフィギュレーションのために cmake を使用するのであれば、 USE_CMAKE を “yes” に設定することにより、適切な手順が実行されます。 CONFIGURE_ENV に変数を追加すると、その変数を cmake の環境変数に追加することができます。また、CMAKE_ARGS 変数に引数を追加すると、 cmake の引数に追加することができます。最上層ディレクトリーを指定する引数は CMAKE_ARG_PATH 変数で与えられるようになっており、この変数の標準の値は “.” (CONFIGURE_DIRS からの相対位置) です。

configure の段階ですることが何もない場合は、 NO_CONFIGURE を “yes” に設定します。

17.12. build 相

パッケージの構築は、大雑把にいえば、以下のコードを実行するのと同じことです。

.for d in ${BUILD_DIRS}
        cd ${WRKSRC} \
        && cd ${d} \
        && env ${MAKE_ENV} \
            ${MAKE_PROGRAM} ${BUILD_MAKE_FLAGS} \
                -f ${MAKE_FILE} \
                ${BUILD_TARGET}
.endfor

BUILD_DIRS (標準では “.”) は、 WRKSRC からの相対位置でのパス名を並べたリストです。この各ディレクトリー内で、環境変数 MAKE_ENV および引数 BUILD_MAKE_FLAGS を使って MAKE_PROGRAM が実行されます。 MAKE_ENV, BUILD_MAKE_FLAGS, MAKE_FILE, BUILD_TARGET の各変数は、いずれもパッケージ側で変更することができます。

MAKE_PROGRAM の標準の値は、 USE_TOOLS に “gmake” が含まれている場合は “gmake”、含まれていない場合は “make” です。 MAKE_FILE の標準の値は “Makefile” であり、 BUILD_TARGET の標準の値は “all” です。

build の段階ですることが何もない場合は、 NO_BUILD を “yes” に設定します。

17.13. test 相

[TODO]

17.14. install 相

構築の段階が完了すると、ユーザーが構築されたプログラムやファイルを使えるようにするため、ソフトウェアをパブリックなディレクトリーにインストールする必要があります。

install 相は、大雑把にいえば、以下のコードを実行するのと同じことです。これに加えて、このコードの前後では、整合性の検査やパッケージの登録などをするため、多くの操作がおこなわれます。

.for d in ${INSTALL_DIRS}
        cd ${WRKSRC} \
        && cd ${d} \
        && env ${MAKE_ENV} \
            ${MAKE_PROGRAM} ${INSTALL_MAKE_FLAGS} \
                -f ${MAKE_FILE} \
                ${INSTALL_TARGET}
.endfor

各変数の意味は、build 相のものと同様です。 INSTALL_DIRS は標準では BUILD_DIRS です。INSTALL_TARGET は標準では “install” ですが、 USE_IMAKE が定義されており、かつ NO_INSTALL_MANPAGES が定義されていない場合は、 “install.man” が追加されます。

install 相では、以下の変数が有用です。これらはいずれも install(1) コマンドの変種であり、所有者、所有グループ、パーミッションをあらかじめ決めてあるものです。 INSTALL は、オプションを何も指定しない install コマンドです。用途別に特化した変種には、以下のものがあります。

INSTALL_PROGRAM_DIR: バイナリーを含むディレクトリー
INSTALL_SCRIPT_DIR: スクリプトを含むディレクトリー
INSTALL_LIB_DIR: 共有静的ライブラリーを含むディレクトリー
INSTALL_DATA_DIR: データファイルを含むディレクトリー
INSTALL_MAN_DIR: マニュアルページを含むディレクトリー
INSTALL_PROGRAM: デバッグ用シンボルを取り除くことのできるバイナリー
INSTALL_SCRIPT: シンボルを取り除くことのできないバイナリー
INSTALL_GAME: ゲームのバイナリー
INSTALL_LIB: 共有静的ライブラリー
INSTALL_DATA: データファイル
INSTALL_GAME_DATA: ゲーム用のデータファイル
INSTALL_MAN: マニュアルページ

これらのほか、以下の変数があります。

INSTALLATION_DIRS: pkgsrc が install 相の最初に作成するディレクトリーを PREFIX からの相対位置表記で並べたリストです。パッケージは、ファイルをインストールする前に、必要なディレクトリーをすべて自力で作成することになるので、その他のディレクトリーをすべてここに列挙します。

稀な場合として、パッケージが何もインストールしないような場合は、 NO_INSTALL を “yes” に設定します。これはほとんどの場合、regress カテゴリーのパッケージに関するものです。

17.15. package 相

install 期が完了すると、インストールされたファイルからなるバイナリーパッケージを作ることができます。このようなバイナリーパッケージは、たとえば make bin-install するか、 pkg_add を使って、それまでのコンパイルの過程を踏まずに、迅速にインストールすることができます。

標準では、バイナリーパッケージは ${PACKAGES}/All に作られ、また、 CATEGORIES 変数に設定されたカテゴリーごとに ${PACKAGES}/category にシンボリックリンクが作られます。PACKAGES は標準では pkgsrc/packages になります。

17.16. 掃除をする

パッケージの作業が終わったら、make clean を実行して作業ディレクトリーを掃除することができます。依存パッケージの作業ディレクトリーもすべて掃除したい場合は、 make clean-depends を使います。

17.17. 他の役に立つターゲット

pre/post-*

前のセクションで述べた主ターゲットのために、二つの補助ターゲットが存在します。これは主ターゲットに“pre-”や“post-”というプレフィックスをつけたものです。これらのターゲットは、特別な設定やインストール手順のために、主ターゲットが実行される前や後に、パッケージの Makefile から実行されます。例えば、プログラムのコンフィギュレーションスクリプトやインストールターゲットが省略された場合に有用です。

do-*

主なターゲットがおかしな動作をし、それを修正するための変数が存在しない場合、do-*ターゲットを使用することにより、それらを再定義することができます (do-*ターゲットのかわりに、ターゲット自体を再定義してはいけません。pre-* やpost-*ターゲットが実行されなくなってしまいます)。通常、再定義する必要はありません。

reinstall

もし、make install実行後に、いくつかのファイルがきちんとインストールされなかった事に気がついた場合、このターゲットを使い、再びインストールする事ができます。この場合、“インストール済み”フラグは無視されます。

これは、DEPENDS_TARGET の標準の値です。ただし make update および make package の場合は例外であり、これらについてはそれぞれ “package” および “update” が標準の値になります。

deinstall

このターゲットは、パッケージをアンインストールするためにカレントディレクトリーでpkg_delete(1)を実行します。動作を制御するために、以下の変数を使用することができます。

PKG_VERBOSE: pkg_delete(1)コマンドに「-v」オプションを渡します。
DEINSTALLDEPENDS: 指定されたパッケージに必要な(依存する)すべてのパッケージを削除します。このターゲットは、指定されたパッケージによってインストールされたパッケージを削除するために使用されます。例えば、make deinstall DEINSTALLDEPENDS=1がpkgsrc/x11/kdeで実行された場合、KDE全体を削除します。pkg_delete(1)のコマンドラインに“-R”を指定すると設定されます。

bin-install

バイナリーパッケージを、ローカルディスクまたは列挙された FTP サイト (BINPKG_SITES 変数を参照) からインストールし、利用可能なバイナリーパッケージがどこにもない場合には make package をおこないます。 pkg_add 用の引数、たとえば饒舌な操作などを BIN_INSTALL_FLAGS に設定することができます。

update

このターゲットは、現在のパッケージを最新のものに更新します。最初にパッケージと、それに依存するすべてのパッケージをアンインストールします。それから最新のバージョンのパッケージをコンパイル、インストールします。これは、現在どのパッケージがインストールされているかを調べ、make deinstall、 make install(または、UPDATE_TARGETで設定されたターゲット)を続けて実行するのと同じです。

以前に実行したmake updateがさまざまな理由で中断された場合、パッケージの更新のために、このターゲットを使用することができます。ただし、この場合は、make cleanを実行していない事、あるいはWRKDIRの依存パッケージのリストを削除していない事を確認してください。そうでなければ、インストール済みの依存パッケージを使用し、現在のパッケージを自動更新することができません。

中断されたmake updateの再開は、パッケージツリーの他の部分が変更されていない場合に限って動作します。更新対象のパッケージのソースコードが変更されていた場合は、make updateの再開はきっと失敗するでしょう。

make updateの動作を変更するために、以下の変数をコマンドライン、またはmk.confで使うことができます。

UPDATE_TARGET: 更新されたパッケージや依存パッケージのために再帰的に使用されるインストールターゲット。 make update用のデフォルトは、DEPENDS_TARGETが設定されている場合はその値、それ以外の場合は“install”です。これら以外のターゲットのよい例としては “package” や “bin-install” があります。ここで “update” を設定してはいけません (無限ループに陥ってしまいます)。
NOCLEAN: 更新した後、きれいに掃除をしません。調査やその他の目的のために、更新されたパッケージの作業用ソース等をそのままにしておきたい場合に役に立ちます。最終的にはソースツリーを掃除してください(以下の “clean-update”ターゲットを見てください)。そうしなければ、次回の makeやmake updateの時に古いソースコードが残っていることでトラブルがおこるかもしれません。
REINSTALL: インストール(make DEPENDS_TARGET)の前に各パッケージをアンインストールします。これは、make updateの実行中断後に“clean-update”ターゲット (以下参照)が呼ばれた場合に必要となることがあります。
DEPENDS_TARGET: 再帰を無効化し、パッケージのターゲットをハードコードすることができます。updateターゲット用のデフォルトは“update”であり、事前に必要なパッケージを再帰的に更新するようになっています。DEPENDS_TARGETを設定するのは、再帰的な更新を無効化したいときだけにしてください。make update (後述します)の最中にインストールされる各パッケージに対して、特定のターゲットを指定するだけの場合は、これのかわりにUPDATE_TARGETを使ってください。

clean-update

カレントディレクトリーでmake updateが実行された時に更新されるすべてのパッケージのソースツリーを掃除します。カレントパッケージ(あるいは、依存パッケージ)がすでにアンインストールされている(例えばmake updateを実行した後)場合には、このターゲットを使ってはいけません。もし使用すると、更新するつもりのパッケージのいくつかを失う可能性があります。経験的には、初めてmake updateを実行する前、あるいは汚れたパッケージツリーがある場合(例えばNOCLEANを使用した場合)にのみ使用するとよいでしょう。

パッケージのツリーが掃除されているかどうかわからない場合は、ツリーの最上層でmake cleanを実行するか、更新しようとしているパッケージのディレクトリーで以下のコマンドをこの順に使うか、どちらかをおこなうことができます。 (make updateを初めて実行するより前におこなってください。それ以外の場合、更新しようとしているパッケージをすべて失ってしまいます)

# make clean-update
# make clean CLEANDEPENDS=YES
# make update

make clean-updateの動作を変更するために、以下の変数をコマンドライン、またはmk.confで使うことができます。

CLEAR_DIRLIST: make cleanの後で、パッケージのためのディレクトリーのリストを再構築しません。make updateで、更新したいすべてのパッケージがインストールされた場合にのみ使用してください。通常、これはmake updateで自動的に実行されます。ただし、NOCLEAN変数の設定によって実行されない事もあります(上を参照してください)。

replace

当該パッケージのインストールを更新します。依存するパッケージの置き換えをおこなわないという点で update と異なります。このターゲットを動作させるためには、pkgtools/pkg_tarup をインストールする必要があります。

このターゲットは注意して使ってください。 このターゲットを使って更新した後に、依存するパッケージが動作するという保証はありません。特に、ライブラリーのパッケージで、共有ライブラリーのメジャーバージョンが変わるようなものを make replace した場合は、ほぼ確実に壊れます。このため、このターゲットは公式にはサポートされておらず、熟練した利用者だけが使うことを推奨します。

info

このターゲットは、現在のパッケージに対してpkg_info(1)をおこないます。これを使って、インストールされているパッケージのバージョンを調べることができます。

index

これは最上層用のコマンド、つまり pkgsrc ディレクトリーで使うコマンドです。ローカルの pkgsrc ツリー内の全パッケージのデータベースを作成します。このデータベースには、依存性、コメント、メンテナー、その他の有用な情報が含まれます。個々のパッケージのエントリーは、当該パッケージのディレクトリーで make describe を実行して作成されます。作成された索引ファイルは pkgsrc/INDEX に保存されます。この索引は、make print-index を実行すると、饒舌な形式で表示することができます。 make search key=something を使って、索引を検索することができます。 make show-deps PKG=somepackage を実行して、特定のパッケージに依存するパッケージをすべて調べることができます。

このコマンドの実行には、非常に長い時間がかかります。速いマシンでも数時間かかるでしょう。

readme

このターゲットは、 README.htmlファイルを作成します。このファイルは www/firefoxや www/linksのようなブラウザーで閲覧することができます。作成されたファイルは、ローカルホストの PACKAGESディレクトリーにあるパッケージへの参照を含んでいます。また、 FTP_PKG_URL_HOSTとFTP_PKG_URL_DIRを元にしたURLを参照させることもできます。例えば、ローカルマシン上の/usr/packagesディレクトリーのバイナリーパッケージを参照するREADME.htmlファイルを作成したい場合、 FTP_PKG_URL_HOST=file://localhostとFTP_PKG_URL_DIR=/usr/packagesをセットしてください。${PACKAGES}ディレクトリーと、そのサブディレクトリーはすべてのバイナリーパッケージで検索されます。

このターゲットは、最上層またはカテゴリーのディレクトリーで実行することもできます。そうした場合は、配下のパッケージに対して再帰的に実行されます。

readme-all

これは最上層用のコマンドであり、pkgsrc で実行します。このターゲットを使い、README-all.htmlを作成することができます。このファイルはNetBSDパッケージコレクションの中の、現在利用可能なすべてのパッケージのリスト、また、それらが属するカテゴリーと簡単な説明を含んでいます。このファイルはpkgsrc/*/README.htmlから作りだされます。したがって、make readme の後に、このターゲットを実行してください。

cdrom-readme

これは“readme”ターゲット(上を見てください)とほとんど同じですが、CD-ROMに焼かれるpkgsrcツリーを作る時に使われます。また、このターゲットは README.htmlファイルを作成し、CDROM_PKG_URL_HOSTとCDROM_PKG_URL_DIRに基づくURLへの参照を作ります。

show-distfiles

このターゲットは、パッケージを構築するために、どのdistfileやパッチファイルが必要か (ALLFILES: DISTFILESおよびPATCHFILESをすべて含みますが、 patches/*は含みません) を表示します。

show-downlevel

このターゲットは、パッケージがインストールされていない場合は何も表示しません。もし、あるバージョンのパッケージがインストールされているが、現在の pkgsrcのバージョンでインストールされたものでない場合、警告メッセージを表示します。このターゲットは、インストール済みのパッケージが古いバージョンであり、そのバージョンが削除可能で、最新の物が追加されることを表示するために使用されます。

show-pkgsrc-dir

当該パッケージの構築とインストールが可能な、パッケージ階層におけるディレクトリーを表示します。このディレクトリーは、そのパッケージがインストールされた際のディレクトリーと同じとは限りません。このターゲットは、単一ホスト上で多数のパッケージの更新をしたい場合に使うためのもので、pkgsrc の最上層のMakefileから“show-host-specific-pkgs”ターゲットで呼び出すことができます。

show-installed-depends

このターゲットは、インストールされているパッケージのうち、どれが当該パッケージのDEPENDSと合致するかを表示します。依存関係が古いせいで構築に問題が起きる場合に便利です。

check-shlibs

パッケージのインストール後に、すべてのバイナリーおよび(ELFプラットフォームでは) 共有ライブラリーが必要な共有ライブラリーを見つけられるかどうか確認します。mk.confでPKG_DEVELOPERが設定されている場合はデフォルトで実行します。

print-PLIST

パッケージを新規に、または更新のために“make install”した後、 find -newer work/.extract_doneをもとに新しいPLISTを生成して表示します。PLIST生成は、共有ライブラリーなどに配慮して行われますが、生成した結果をPLISTに置く前に再確認するよう強くおすすめします。パッケージ更新時には、このコマンドの出力と、更新前のPLISTファイルとを比較すると便利でしょう。

パッケージが、tar(1)その他のファイルのアクセス時刻を更新しない方法を使ってファイルをインストールする場合は、それらのファイルはこのターゲットで使われる “find -newer” コマンドで検出されないので、手でPLISTに書き足すよう注意してください!

このターゲットに関するさらなる情報は、 Section 13.3, “make print-PLIST の出力を細工する”を参照してください。

bulk-package

バルクビルドの実行に使われます。適切なバイナリーパッケージがすでに存在する場合は、何もしません。そうでない場合は、コンパイル、インストール、パッケージ作成をおこないます (PKG_DEPENDSが適切に設定されている場合は、依存するパッケージも。Section 7.3.1, “設定”参照)。バイナリーパッケージ作成後、ディスクの空き領域を確保するために、ソース、インストールしたばかりのパッケージと依存パッケージは削除されます。

このターゲットを使うと、システムにインストールされているパッケージをすべてアンインストールすることもあるので、注意してください。

bulk-install

依存パッケージ群をインストールするためのバルクインストールで使われます。最新のバイナリーパッケージが利用可能な場合、pkg_add(1)でそれをインストールします。そうでない場合は、make bulk-packageが実行されますが、インストールされたバイナリーは削除されません。

バイナリーパッケージが“最新”であるとみなされる (pkg_add(1) でインストールされる) 条件は、以下のとおりです。

パッケージファイル (Makefile, ...)が、いずれも構築時から変更されていないこと。
そのパッケージが依存している(バイナリー) パッケージが、いずれも構築時から変更されていないこと。

このターゲットを使うと、システムにインストールされているパッケージをすべてアンインストールすることもあるので、注意してください。

Prev	Up	Next
Chapter 16. オプションの扱い	Home	Chapter 18. 構築や実行のために必要なツール