Table of Contents
本章では、パッケージがどのように構築されるかについて、詳しく説明します。
パッケージの構築は、複数の相 (phase) (たとえば、fetch
,
build
, install
) にわかれており、
そのすべてを以下の各節で説明します。それぞれの段階は、pre-
,
do-
, post-
のいずれかが相名の前についた、いわゆる期 (stage)
にわかれます。(たとえば、
pre-configure
, post-build
などです。)
実際に何かがおこなわれるのは、ほとんどが do-*
期においてです。
標準的なターゲット (fetch
など) は、決して上書きしないでください。変更する必要がある場合は、
対応する do-*
ターゲットを上書きしてください。
プログラムを構築するための基本的な手順は常に同じです。最初に、プログラムの ソースファイル(distfile)をローカルシステムへ持ってきて展開します。 コンパイルするための pkgsrc 独自のパッチを適用した後に、ソフトウェアを設定 し、構築(通常、コンパイルすることによって)します。最後に作成されたバイナリー 等を、システムにインストールします。
それぞれの段階で何が起きているかを、もっと詳しく把握するために、
PKG_VERBOSE
変数を設定することができます。
または、patch の段階における詳細に関心があるだけなら、
PATCH_DEBUG
変数を設定することもできます。
次のセクションで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
にインストールします。
パッケージの構築時には、ソースファイル、一時ファイル、 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 にしてください。
make phase (phase は相の名前) と打てば、
その相を実行することができます。
こうすると、その相のために必要な相をすべて自動的に実行します。
相を指定しない場合は build
相になります。つまり、
あるパッケージのディレクトリーで、引数なしで make
を実行すると、パッケージが構築されますが、インストールはされません。
パッケージの構築の最初の段階は、配布ファイル (distfiles) を、そのファイルを配布しているサイトから取得することです。 これは fetch 相がおこなう仕事です。
単純な場合では、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
があり、それらが異なるサイトで配布されている場合は、
ファイル (サフィックスを含む) の配布場所の URL を並べたリストを
distfile
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/}
サブディレクトリー名の後のスラッシュ/に注意してください。
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 はミラーされません。
distfileを取得した後に、チェックサムを生成し、distinfoファイルに保存され たチェックサムと比較します。もし、チェックサムが一致しなければ、構築は中 断されます。これはパッケージ作成時と同じdistfileが、構築に使用されている こと、つまり、悪意や一次配布サイトでの意図的な差し替えやネットワークの損 失によってdistfileが変更されていないことを保証するためです。
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
ターゲットを上書きすることができます。
展開の後で、PATCHFILES
で指定されたパッチとパッケージのpatchesサブディレ
クトリーに存在するパッチ、さらに、$LOCALPATCHES/$PKGPATH (たとえば
/usr/local/patches/graphics/png
)に存在するパッチのすべてが適用されます。
.Z
、あるいは.gz
で終る名前のパッチファイルは、適用する前に伸張されます。
.orig
、.rej
で終るものは無視されます。patch(1)のためのいくつかのオプショ
ンは、PATCH_DIST_ARGS
で指定する事ができます。
詳細に関してはSection 11.3, “patches/*”を参照して下さい。
デフォルトでは、パッチに曖昧さがあった場合にはpatch(1)が異常終了するような 特別な引数が渡されます。パッチを修正(再作成)して、きれいに適用できるよう にしてください。そうする理由は、曖昧さがあるパッチが一見うまく適用できても、実は誤った場 所に適用されていて、深刻な問題を起こす可能性があるからです。
この相についてはChapter 18, 構築や実行のために必要なツール で説明しています。
この相では、コンパイラーとリンカー用のラッパープログラムが作成されます。 以下の変数を使って、ラッパーに手を加えることができます。
ECHO_WRAPPER_MSG
経過を表示するためのコマンドです。
標準状態では何もしません。
経過を見るには、この変数を ${ECHO}
に設定します。
WRAPPER_DEBUG
この変数は、
ラッパーのログファイルにより詳しい情報が必要かどうかに応じて、
yes
(標準状態の値) または
no
に設定することができます。
WRAPPER_UPDATE_CACHE
この変数は、
ラッパーの速度を改善するためキャッシュを使わせるかどうかに応じて、
yes
または no
に設定することができます。標準状態の値は
yes
ですが、キャッシュに対応していないプラットフォームでは
強制的に no
になります。
WRAPPER_REORDER_CMDS
順序の並び替え用のコマンドを並べたリストです。
並び替え用のコマンドは、
reorder:l:
のような形式をしています。これを使うと
lib1
:lib2
-l
が常に
lib1
-l
より先に現れるようになります。
lib2
WRAPPER_TRANSFORM_CMDS
変換用のコマンドを並べたリストです。 [TODO: investigate further]
ほとんどのソフトウェアは、実行対象のプラットフォームで利用できるヘッダーファイル、 システムコール、およびライブラリールーチンについての情報を必要とします。 この情報の判断はコンフィギュレーションとして知られているプロセスであり、 通常、自動化されています。 大抵の場合、スクリプトが配布物と一緒に提供され、 それを実行することによりヘッダーファイルや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” に設定します。
パッケージの構築は、大雑把にいえば、 以下のコードを実行するのと同じことです。
.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” に設定します。
構築の段階が完了すると、ユーザーが構築されたプログラムやファイルを使えるようにするため、ソフトウェアをパブリックなディレ クトリーにインストールする必要があります。
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
カテゴリーのパッケージに関するものです。
install 期が完了すると、 インストールされたファイルからなるバイナリーパッケージを作ることができます。 このようなバイナリーパッケージは、たとえば make bin-install するか、 pkg_add を使って、それまでのコンパイルの過程を踏まずに、 迅速にインストールすることができます。
標準では、バイナリーパッケージは
${PACKAGES}/All
に作られ、また、
CATEGORIES
変数に設定されたカテゴリーごとに
${PACKAGES}/
にシンボリックリンクが作られます。category
PACKAGES
は標準では pkgsrc/packages
になります。
パッケージの作業が終わったら、make clean を実行して作業ディレクトリーを掃除することができます。 依存パッケージの作業ディレクトリーもすべて掃除したい場合は、 make clean-depends を使います。
前のセクションで述べた主ターゲットのために、二つの補助ターゲットが存在し ます。これは主ターゲットに“pre-”や“post-”というプレフィックスをつけ たものです。これらのターゲットは、特別な設定やインストール手順のために、 主ターゲットが実行される前や後に、パッケージの Makefile から実行されます。例えば、プログラムのコンフィ ギュレーションスクリプトやインストールターゲットが省略された場合に有用で す。
主なターゲットがおかしな動作をし、それを修正するための変数が存在しない場 合、do-*ターゲットを使用することにより、それらを再定義することができます (do-*ターゲットのかわりに、ターゲット自体を再定義してはいけません。pre-* やpost-*ターゲットが実行されなくなってしまいます)。通常、再定義する必要 はありません。
もし、make install実行後に、いくつかのファイルがきちんとインストール されなかった事に気がついた場合、このターゲットを使い、再びインストールす る事ができます。この場合、“インストール済み”フラグは無視されます。
これは、DEPENDS_TARGET
の標準の値です。ただし make update および make
package の場合は例外であり、これらについてはそれぞれ
“package” および “update”
が標準の値になります。
このターゲットは、パッケージをアンインストールするためにカレントディレク トリーでpkg_delete(1)を実行します。動作を制御するために、以下の変数を 使用することができます。
PKG_VERBOSE
pkg_delete(1)コマンドに「-v」オプションを渡します。
DEINSTALLDEPENDS
指定されたパッケージに必要な(依存する)すべてのパッケージを削除します。
このターゲットは、指定されたパッケージによってインストールされたパッ
ケージを削除するために使用されます。例えば、make deinstall
DEINSTALLDEPENDS=1がpkgsrc/x11/kde
で実行された場合、KDE全体を削除し
ます。pkg_delete(1)のコマンドラインに“-R”を指定すると設定されます。
バイナリーパッケージを、
ローカルディスクまたは列挙された FTP サイト
(BINPKG_SITES
変数を参照)
からインストールし、
利用可能なバイナリーパッケージがどこにもない場合には
make package をおこないます。
pkg_add 用の引数、たとえば饒舌な操作などを
BIN_INSTALL_FLAGS
に設定することができます。
このターゲットは、現在のパッケージを最新のものに更新します。最初にパッケー
ジと、それに依存するすべてのパッケージをアンインストールします。それから
最新のバージョンのパッケージをコンパイル、インストールします。これは、現
在どのパッケージがインストールされているかを調べ、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
を使ってく
ださい。
カレントディレクトリーで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
変数の設定によって実行されない事もあ
ります(上を参照してください)。
当該パッケージのインストールを更新します。
依存するパッケージの置き換えをおこなわないという点で
update と異なります。
このターゲットを動作させるためには、pkgtools/pkg_tarup
をインストールする必要があります。
このターゲットは注意して使ってください。 このターゲットを使って更新した後に、 依存するパッケージが動作するという保証はありません。 特に、ライブラリーのパッケージで、 共有ライブラリーのメジャーバージョンが変わるようなものを make replace した場合は、ほぼ確実に壊れます。 このため、このターゲットは公式にはサポートされておらず、 熟練した利用者だけが使うことを推奨します。
このターゲットは、現在のパッケージに対してpkg_info(1)をおこないます。これ を使って、インストールされているパッケージのバージョンを調べる ことができます。
これは最上層用のコマンド、つまり pkgsrc
ディレクトリーで使うコマンドです。
ローカルの pkgsrc ツリー内の全パッケージのデータベースを作成します。
このデータベースには、依存性、コメント、メンテナー、
その他の有用な情報が含まれます。
個々のパッケージのエントリーは、当該パッケージのディレクトリーで
make describe を実行して作成されます。
作成された索引ファイルは
pkgsrc/INDEX
に保存されます。
この索引は、make
print-index を実行すると、饒舌な形式で表示することができます。
make search
key=something
を使って、索引を検索することができます。
make show-deps
PKG=somepackage
を実行して、特定のパッケージに依存するパッケージをすべて調べることができます。
このコマンドの実行には、非常に長い時間がかかります。 速いマシンでも数時間かかるでしょう。
このターゲットは、
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}
ディレクトリーと、そのサブディレクトリーはすべ
てのバイナリーパッケージで検索されます。
このターゲットは、最上層またはカテゴリーのディレクトリーで実行することもできます。 そうした場合は、配下のパッケージに対して再帰的に実行されます。
これは最上層用のコマンドであり、pkgsrc
で実行します。
このターゲットを使い、README-all.html
を作成することができます。このファ
イルはNetBSDパッケージコレクションの中の、現在利用可能なすべてのパッケー
ジのリスト、また、それらが属するカテゴリーと簡単な説明を含んでいます。こ
のファイルはpkgsrc/*/README.html
から作りだされます。したがって、make
readme
の後に、このターゲットを実行してください。
これは“readme”ターゲット(上を見てください)とほとんど同じですが、CD-ROMに焼
かれるpkgsrcツリーを作る時に使われます。また、このターゲットは
README.html
ファイルを作成し、CDROM_PKG_URL_HOST
とCDROM_PKG_URL_DIR
に基づ
くURLへの参照を作ります。
このターゲットは、パッケージを構築するために、どのdistfileやパッチファイ
ルが必要か (ALLFILES
:
DISTFILES
およびPATCHFILES
をすべて含みますが、
patches/*
は含みません) を表示します。
このターゲットは、パッケージがインストールされていない場合は何も表示しま せん。もし、あるバージョンのパッケージがインストールされているが、現在の pkgsrcのバージョンでインストールされたものでない場合、警告メッセージを表 示します。このターゲットは、インストール済みのパッケージが古いバージョン であり、そのバージョンが削除可能で、最新の物が追加されることを表示するた めに使用されます。
当該パッケージの構築とインストールが可能な、パッケージ階層におけるディレ クトリーを表示します。このディレクトリーは、そのパッケージがインストール された際のディレクトリーと同じとは限りません。このターゲットは、単一ホス ト上で多数のパッケージの更新をしたい場合に使うためのもので、pkgsrc の最 上層のMakefileから“show-host-specific-pkgs”ターゲットで呼び出すことがで きます。
このターゲットは、インストールされているパッケージのうち、どれが当該パッ
ケージのDEPENDS
と合致するかを表示します。依存関係が古いせいで構築に問題が
起きる場合に便利です。
パッケージのインストール後に、すべてのバイナリーおよび(ELFプラットフォー
ムでは) 共有ライブラリーが必要な共有ライブラリーを見つけられるかどうか確
認します。mk.conf
でPKG_DEVELOPER
が設定されている場合はデフォルトで
実行します。
パッケージを新規に、または更新のために“make install”した後、
find -newer
work/.extract_doneをもとに新しいPLIST
を生成して表示します。PLIST生成は、
共有ライブラリーなどに配慮して行われますが、生成した結果をPLIST
に置く前
に再確認するよう強くおすすめします。パッケージ更新時には、このコマンド
の出力と、更新前のPLIST
ファイルとを比較すると便利でしょう。
パッケージが、tar(1)その他のファイルのアクセス時刻を更新しない方法を使っ
てファイルをインストールする場合は、それらのファイルはこのターゲットで使われる “find
-newer” コマンドで検
出されないので、手でPLIST
に書き足すよう注意してください!
このターゲットに関するさらなる情報は、 Section 13.3, “make print-PLIST の出力を細工する”を参照してください。
バルクビルドの実行に使われます。適切なバイナリーパッケージがすでに存在す
る場合は、何もしません。そうでない場合は、コンパイル、インストール、パッ
ケージ作成をおこないます
(PKG_DEPENDS
が適切に設定されている場合は、依存するパッケージも。Section 7.3.1, “設定”参照)。
バイナリーパッケージ作成後、ディスクの空き領域
を確保するために、ソース、インストールしたばかりのパッケージと依存パッケー
ジは削除されます。
このターゲットを使うと、 システムにインストールされているパッケージをすべてアンインストールすることもあるので、 注意してください。
依存パッケージ群をインストールするためのバルクインストールで使われます。 最新のバイナリーパッケージが利用可能な場合、pkg_add(1)でそれをインストール します。そうでない場合は、make bulk-packageが実行されますが、インストー ルされたバイナリーは削除されません。
バイナリーパッケージが“最新”であるとみなされる (pkg_add(1) でインストールされる) 条件は、以下のとおりです。
パッケージファイル
(Makefile
, ...)が、いずれも構築時から変更されていな
いこと。
そのパッケージが依存している(バイナリー) パッケージが、いずれも構築時から変更されていないこと。
このターゲットを使うと、 システムにインストールされているパッケージをすべてアンインストールすることもあるので、 注意してください。