訳註: これは作業してる最中のもので、本来、訳作業者以外は見えぬべきものです。 訳作業者以外は見ないでください。意味が反対になったりとか当然にあるから、 内容は利用しないでください。この言語への変換作業(翻訳作業)物に関しては、現在、オープンなライセンス条件ではありません。 十進240のコードのキャラクターを<240>に置換してる場合あり
Chapter31.Crosscompiling NetBSD with build.sh

Table of Contents

31.1. Building the crosscompiler
31.2. Configuring the kernel manually
31.3. Crosscompiling the kernel manually
31.4. Crosscompiling the kernel with build.sh
31.5. Crosscompiling the userland
31.6. Crosscompiling the X Window System
31.7. Changing build behaviour
31.7.1. Changing the Destination Directory
31.7.2. Static Builds
31.7.3. Using build.sh options
31.7.4. make(1) variables used during build

訳者註:誰がどう見ても作業中だってわかりますが、
(31.7.4 はもちろんの事、全体に いくらかの単語単位で変換し置いてあるだけなので、無理に日本語的に読むとおかしくなります、 そこまですら行ってないけど)
ファイル無くさないようにここに置かれていることがあります。
消えたりちょっとだけ進んだのが置かれることがありますが、
すくなくても、ここの註書きが消えるまでは、いつの日にか更新されます。
訳者註おわり

組み込みプラットホーム product を targeting するとき、全ての開発ツールを 同一プラットホーム上で利用可能なものにするのは可能なことではありません。 代わって、いくつかのクロスコンパイル方法が、今日、普通に使われています。 NetBSD 1.6 および以降では、コンパイラーが runs しているのと同じプラットホームへ、 または クロスコンパイルを用いた異なるプラットホームへ、の両方で オペレーティングシステムのカーネルおよびユーザーランド全体双方を構築するための 枠組みが付属しています。 クロスコンパイルは、利用可能であってプラットホームを構築するため、に、 アセンブラー、リンカー、コンパイラー等を要求します。新しい構築機構は 与えられたプラットホーム向けのこれらツールの作成を世話してくれて、 開発作業するのに使えるように利用可能に準備します。

この章では、 build.sh の利用法、 クロスコンパイラー、クロスアセンブラー、クロスリンカー、等々を含む クロスコンパイル toolchain の初めての作り方を示します。 native カーネル構築は Chapter32, Compiling the kernel で扱いましたが、これらのツールを 手設定で、および異なるプラットホームのカーネルのクロスコンパイルに使い、 そしてそれから、便利な代替品として build.sh の利用法を示します。その作業の後、 NetBSD ユーザーランド全体をコンパイルし、そして、 NetBSD リリース形式に packed up します。例では、 Sun UltraSPARC ("sparc64") 64-bit プラットホーム を target プラットホーム に用い、 NetBSD でサポートしている any 他のプラットホーム もその名前を指定することでまた targetted できます ( /usr/src/sys/arch を御覧ください)。

始める前に、メモとして、 Chapter30, Obtaining the sources に記述されているように /usr/src に "netbsd-4-0" ブランチの NetBSD ソースが利用可能と仮定します。

build.sh フレームワーク のさらに詳細な記述は /usr/src/BUILDING と同様に、 Luke Mewburn 氏および Matthew Green 氏の paper および、彼等の BSDCon 2003 からの presentation があります。

31.1.Building the crosscompiler

cross-development を do 最初のステップは、全ての必要なツールを利用可能にすることです。 NetBSD 用語では、これを "toolchain" と呼び、 BSD-互換 make(1) 、 C/C++ コンパイラー、リンカー、アセンブラー、 config(8) が含まれ、同様に 完全 NetBSD リリースをクロスコンパイルする時だけ必要な相当な数のツール も含まれていますが、そちらについては ここでは cover ません。

クロスコンパイラーを作るコマンドは非常にシンプルで、 NetBSD の新しい src/build.sh スクリプトを用います。 どうか注意として、ここの全コマンドは通常の(ルートでない)ユーザーで run でき:

$ cd /usr/src
$ ./build.sh -m sparc64 tools

/usr/obj ディレクトリーがあること、 または、 object ディレクトリーをどこか他に置くなら、 build.sh の call に "-O" オプションを つけるよう、確実に手配してください。

ツールを以前構築しているなら、必要なことはアップデートだけで、 ツールに変更があったときにだけ 再構築するように、アップデートオプション "-u" が使えます:

$ ./build.sh -u -m sparc64 tools

ツールが構築されたら、それらの情報および、いくつかの環境変数が printed out されます:

...
===> build.sh started: Thu Dec  2 22:18:11 CET 2007
===> build.sh ended:   Thu Dec  2 22:28:22 CET 2007
===> Summary of results:
         build.sh command: ./build.sh -m sparc64 tools
         build.sh started: Thu Dec  2 22:18:11 CET 2007
         No nonexistent/bin/nbmake, needs building.
         Bootstrapping nbmake
         MACHINE:          sparc64
         MACHINE_ARCH:     sparc64
         TOOLDIR path:     /usr/src/tooldir.NetBSD-4.0-i386
         DESTDIR path:     /usr/src/destdir.sparc64
         RELEASEDIR path:  /usr/src/releasedir
         Created /usr/src/tooldir.NetBSD-4.0-i386/bin/nbmake
         makewrapper:      /usr/src/tooldir.NetBSD-4.0-i386/bin/nbmake-sparc64
         Updated /usr/src/tooldir.NetBSD-4.0-i386/bin/nbmake-sparc64
         Tools built to /usr/src/tooldir.NetBSD-4.0-i386
         build.sh started: Thu Dec  2 22:18:11 CET 2007
         build.sh ended:   Thu Dec  2 22:28:22 CET 2007
===> . 

build 中、 object ディレクトリーは徹底的に使われます。 すなわち、特別なディレクトリーが保持され、 プラットホーム-固有の object ファイルおよびコンパイル結果を保存します。 our 例では、 target プラットホームとして UltraSPARC に構築したものは "obj.sparc64" と名づけられたディレクトリーに保有されています。

toolchain それ自身がこれの一部ですが、しかし i386 システムに、 hosted とコンパイルをされ、 それ自身のディレクトリーに位置し、どれからクロス構築されるかを示します。 我等がクロスコンパイラーツールの位置は:

$ pwd
/usr/src
$ ls -d tooldir.*
tooldir.NetBSD-4.0-i386

それで、総合的経験則は、与えられた "host" および "target" システムの組み合わせに対し、クロスコンパイラーを "src/tooldir.host" ディレクトリーに default で配置することです。 NetBSD オペレーティングシステム全体をクロスコンパイルするため作られる全ツールの完全なリストは includes:

$ ls tooldir.NetBSD-4.0-i386/bin/
nbasn1_compile          nbmakefs                nbzic
nbcap_mkdb              nbmakeinfo              sparc64--netbsd-addr2li
nbcat                   nbmakewhatis            sparc64--netbsd-ar
nbcksum                 nbmenuc                 sparc64--netbsd-as
nbcompile_et            nbmkcsmapper            sparc64--netbsd-c++
nbconfig                nbmkdep                 sparc64--netbsd-c++filt
nbcrunchgen             nbmkesdb                sparc64--netbsd-cpp
nbctags                 nbmklocale              sparc64--netbsd-dbsym
nbdb                    nbmknod                 sparc64--netbsd-g++
nbeqn                   nbmktemp                sparc64--netbsd-g77
nbfgen                  nbmsgc                  sparc64--netbsd-gcc
nbfile                  nbmtree                 sparc64--netbsd-gcc-3.3
nbgencat                nbnroff                 sparc64--netbsd-gccbug
nbgroff                 nbpax                   sparc64--netbsd-gcov
nbhexdump               nbpic                   sparc64--netbsd-ld
nbhost-mkdep            nbpwd_mkdb              sparc64--netbsd-lint
nbindxbib               nbrefer                 sparc64--netbsd-mdsetim
nbinfo                  nbrpcgen                sparc64--netbsd-nm
nbinfokey               nbsoelim                sparc64--netbsd-objcopy
nbinstall               nbstat                  sparc64--netbsd-objdump
nbinstall-info          nbsunlabel              sparc64--netbsd-ranlib
nbinstallboot           nbtbl                   sparc64--netbsd-readelf
nblex                   nbtexi2dvi              sparc64--netbsd-size
nblorder                nbtexindex              sparc64--netbsd-strings
nbm4                    nbtsort                 sparc64--netbsd-strip
nbmake                  nbuudecode
nbmake-sparc64          nbyacc 

見られるように、ほとんどのツールが NetBSD 上で native で利用可能で、いくつかのプログラムには ある target プラットホームに固有のツールに target プラットホームを識別子として prefix がついています。

ここで指摘しておくべき1つのツールは、 "nbmake-sparc64" です。 これは BSD 互換 make(1) コマンドに対するシェルラッパーで、 クロスコンパイラー toolchain からすべて正しいコマンドを使うようにセットアップします。 /usr/bin/make の代わりに、このラッパーを使うことで、 the NetBSD Makefile infrastructure (src/share/mk を見てください) を使うように書かれたプログラムでクロスコンパイリングができます。 この make(1) ラッパーの利用で、 カーネルはたちまちクロスコンパイルされます!

31.2.Configuring the kernel manually

これで、 working クロスコンパイラーが利用可能で、 カーネル構築の "usual" ステップが必要で - カーネル設定ファイルを作り、 config(8) を run し、それから build します。 カーネル構築のため、ヘッダーファイルおよび Makefile の生成に使われる config(8) プログラムがプラットホーム特定のものに対して、 新しい toolchain の一部である "nbconfig" プログラム を使う必要があります。それは置いといて、 手順は単なる "native" NetBSD カーネルのコンパイルみたいな感じです。ここで必要なコマンドは:

$ cd /usr/src/sys/arch/sparc64/conf
$ cp GENERIC MYKERNEL
$ vi MYKERNEL
$ /usr/src/tooldir.NetBSD-4.0-i386/bin/nbconfig MYKERNEL

それだけ。このコマンドで、ディレクトリー ../compile/MYKERNEL が作られ、そこにコンパイルするためカーネルの中に入れるデバイスに ついての情報を定義した多数のヘッダーファイルが置かれ、 カーネルのための構築に必要な全ファイルの setup と、それを一緒にリンクするための Makefile がつくられます。

31.3.Crosscompiling the kernel manually

この Intel-based ホストシステムで UltraSPARC-based カーネルを クロスコンパイルする全ファイル、ツールが利用可能です。 やりましょう! 前のステップで作られたディレクトリーに移動した後、 クロスコンパイラー toolchain の nbmake-sparc64 シェルラッパーを使い、それは sparc64 プラットホームのクロスコンパイルに必要な全てを つけて make(1) を calls するだけで:

$ cd ../compile/MYKERNEL/
$ /usr/src/tooldir.NetBSD-4.0-i386/bin/nbmake-sparc64 depend
$ /usr/src/tooldir.NetBSD-4.0-i386/bin/nbmake-sparc64

少し激しくかきまわすと、そうすっと、カーネルが吐き出され:

...
   text    data     bss     dec     hex filename
5016899  163728  628752 5809379  58a4e3 netbsd
$ ls -l netbsd
-rwxr-xr-x  1 feyrer  666  5874663 Dec  2 23:17 netbsd
$ file netbsd
netbsd: ELF 64-bit MSB executable, SPARC V9, version 1 (SYSV), statically linked, not stripped 

さて、 netbsd ファイルのカーネルは、 UltraSPARC machine (NFS 、 FTP 、 scp 、等経由) に転送し possible ハードディスクから booted するか、 または NFS を用いて cross-development machine のディレクトリーからか どららでもできます。

カーネルの configuring およびクロスコンパイルの後、次の logical ステップはシステム全体をクロスコンパイルし、 配布-可能形式にまでします。そうする前に、 代替手法によるカーネルクロスコンパイルは次の節に示され、 build.sh スクリプトを用い、カーネルの [configのことだから"設定"にしないほうがいいと思う]設定およびクロスコンパイルを1つのステップで行います。

31.4.Crosscompiling the kernel with build.sh

クロスコンパイルされたカーネル は前の節で記述されたように手作業で done でき、 または、ここに示すように、 build.sh を使って行う方法がもっと簡単です。

準備するカーネル設定ファイルは 上に記述されたのと同じく:

$ cd /usr/src/sys/arch/sparc64/conf
$ cp GENERIC MYKERNEL
$ vi MYKERNEL 

それから MYKERNEL を編集し、一度終わると、 完了にまでするべき全てのこととは、 カーネル構築に build.sh を使うことです。 (上で示したステップで running のように configure もします):

$ cd /usr/src
$ ./build.sh -u -m sparc64 kernel=MYKERNEL

注意として、 update ("-u") が指定されています。ツールは既に構築されていて、 ツールの全部を再構築する理由はありません。 一度カーネルが構築されると、 build.sh は 他の情報と一緒に位置を表示します:

...
===> Summary of results:
         build.sh command: ./build.sh -u -m sparc64 kernel=MYKERNEL
         build.sh started: Thu Dec  2 23:30:02 CET 2007
         No nonexistent/bin/nbmake, needs building.
         Bootstrapping nbmake
         MACHINE:          sparc64
         MACHINE_ARCH:     sparc64
         TOOLDIR path:     /usr/src/tooldir.NetBSD-4.0-i386
         DESTDIR path:     /usr/src/destdir.sparc64
         RELEASEDIR path:  /usr/src/releasedir
         Created /usr/src/tooldir.NetBSD-4.0-i386/bin/nbmake
         makewrapper:      /usr/src/tooldir.NetBSD-4.0-i386/bin/nbmake-sparc64
         Updated /usr/src/tooldir.NetBSD-4.0-i386/bin/nbmake-sparc64
         Building kernel without building new tools
         Building kernel:  MYKERNEL
         Build directory:  /usr/src/sys/arch/sparc64/compile/obj.sparc64/GENERIC
         Kernels built from MYKERNEL:
          /usr/src/sys/arch/sparc64/compile/obj.sparc64/MYKERNEL/netbsd
         build.sh started: Thu Dec  2 23:30:02 CET 2007
         build.sh ended:   Thu Dec  2 23:38:22 CET 2007
===> . 

ここで関心があるのは、構築されたカーネルのパスで: /usr/src/sys/arch/sparc64/compile/obj.sparc64/MYKERNEL/netbsd 、 上で記述されたのと同様に使えます。

31.5.Crosscompiling the userland

今から多分、 in stages の実際の toolchain の works が明らかになっていくでしょう。 最初にクロスコンパイラーが構築され、それからカーネルです。 build.sh は invocation たびに ツールの再構築を試みるので、 update の利用で時間が節約されます。幾つかのオプションの outside が clear にもなるでしょう、 build.sh semantics は基本的に build.sh command。 それで、それは ユーザーランド全体 および/または リリースの構築は 正しいコマンドを利用する事の理由と主張します。

構築とリリースの作成が次のようであっても、驚くべきことではありません:

$ ./build.sh -U -u -m sparc64 release

これらのコマンドで full NetBSD ユーザーランドをコンパイルし、それを destination ディレクトリー内に put し、それをもとに、リリースディレクトリーに リリースを構築します。ここで加えられた -U スイッチは unprivileged(特権なき) 構築で、すなわち、 誰かが、通常ユーザーとしてであって、 root としてではなく running します。 build.sh に他のスイッチを与えたり 環境変数を何もセットしなければ、 build.sh の出力として上で示された defaults の DESTDIR=/usr/src/destdir.sparc64 および RELEASEDIR=/usr/src/releasedir が使われます。

31.6.Crosscompiling the X Window System

The NetBSD project は X Window System ソースの独自のコピーを持っていて、現在 XFree86 version 4 ベースで、 できるだけ NetBSD がサポートしている多くのプラットホームに X が使えるよう変更が入っています。このため、 NetBSD から/へ 利用可能な X Window System version を使う事が妥当で、これはまた、 カーネルおよび base システムのようにクロスコンパイルできます。 そうするためには、 "xsrc" ソースを Chapter30, Obtaining the sources に記述されている "src" および "pkgsrc" のように、 CVS から /usr/xsrc にチェックアウトしなければなりません。

この後、 X は -x スイッチを build.sh に加えることで、 target プラットホーム 向けにクロスコンパイルできて、例. フルリリース作成時:

$ ./build.sh -U -x -u -m sparc64 release

-U フラグを unprivileged[特権なき] (非-root) 構築するために、そして -u フラグを構築前に古いファイルを除去しないために、 同様に -m arch オプションは target アーキテクチャーを定義する、は既に紹介されていて、そして -x オプションが "xsrc" も(クロス)コンパイルするための 別のオプションです。

31.7.Changing build behaviour

古い、手作業の構築方法に似て、新しい toolchain には沢山の変数があって、 あるファイルがどこに行くか、(例えあるとしても)どのツールが使われるか等のような事 を指図するのに使われます。 src/BUILDING を見れば そのほとんどを covers しています。この節では、いくつかの default 設定の変更例、それがどのようになるかが与えられます。

31.7.1.Changing the Destination Directory

多くの人々が NetBSD-current を追跡し、 利用しているアーキテクチャーのクロスコンパイルをします。この論理は単純で 時々、新機能やデバイスが利用可能になり、そして誰かがそれを使いたいと望みます。 時折、変更の追跡と構築を続けることで、 これらのアーキテクチャーで自分のリリースを構築できることが確約されます。

誰かが1つを越えるアーキテクチャーを追いかけ構築すると仮定するのは道理が通ることで、 default と異なる位置に構築物を keep したいかもしれません。 これに関して2つの方法で行けて、 新しい DESTDIR を設定するスクリプトを使うか、または、簡単に interactively(対話式に)します。どの場合も、 any 他の変数同様設定できます。(もちろんあなたのシェルに依存します)。

bash 、 Bourne または Korn シェルには、これは:

$ export DESTDIR=/usr/builds/sparc64

tcsh および C シェルには、コマンドは:

$ setenv DESTDIR /usr/builds/sparc64

Simple で十分です。 build を run したとき、バイナリーとファイルは、 /usr/builds に送られます。

31.7.2.Static Builds

NetBSD toolchain は default では共有ライブラリーを構築しリンクします。 多くのユーザーは、今でも 静的リンクを好みます。時には小さなシステムで共有ライブラリーを 持たさずに作ることができて、これは完全静的構築を行う良い例です。 特定の構築 machine がいつも環境変数を設定する必要があるなら、 変更する設定を /etc/mk.conf に加えるのが最も簡単です。

build box で、いつも静的に構築するように確実にするには、 /etc/mk.conf に簡素に次の行を加え:

LDSTATIC=-static

31.7.3.Using build.sh options

環境の変数および /etc/mk.conf の他にも、 強制 unprivileged[特権なき] (非-root) 構築、 target アーキテクチャーの選択や構築前の古いファイル削除の阻止で既に見たように build.sh スクリプト自身の沢山のスイッチで 構築プロセスは影響を受けます。これら全てのオプションは build.sh -h を running すると listed でき:

$ cd /usr/src
$ build.sh -h
Usage: build.sh [-EnorUux] [-a arch] [-B buildid] [-D dest] [-j njob]
		[-M obj] [-m mach] [-N noisy] [-O obj] [-R release] [-T tools]
		[-V var=[value]] [-w wrapper] [-X x11src] [-Z var]
		operation [...]

 Build operations (all imply "obj" and "tools"):
    build               Run "make build".
    distribution        Run "make distribution" (includes DESTDIR/etc/ files).
    release             Run "make release" (includes kernels and distrib media).

 Other operations:
    help                Show this message and exit.
    makewrapper         Create nbmake-${MACHINE} wrapper and nbmake.
                        Always performed.
    obj                 Run "make obj".  [Default unless -o is used]
    tools               Build and install tools.
    install=idir        Run "make installworld" to `idir' to install all sets
			except `etc'.  Useful after "distribution" or "release"
    kernel=conf         Build kernel with config file `conf'
    releasekernel=conf  Install kernel built by kernel=conf to RELEASEDIR.
    sets                Create binary sets in RELEASEDIR/MACHINE/binary/sets.
			DESTDIR should be populated beforehand.
    sourcesets          Create source sets in RELEASEDIR/source/sets.
    params              Display various make(1) parameters.

 Options:
    -a arch     Set MACHINE_ARCH to arch.  [Default: deduced from MACHINE]
    -B buildId  Set BUILDID to buildId.
    -D dest     Set DESTDIR to dest.  [Default: destdir.MACHINE]
    -E          Set "expert" mode; disables various safety checks.
                Should not be used without expert knowledge of the build system.
    -j njob     Run up to njob jobs in parallel; see make(1) -j.
    -M obj      Set obj root directory to obj; sets MAKEOBJDIRPREFIX.
                Unsets MAKEOBJDIR.
    -m mach     Set MACHINE to mach; not required if NetBSD native.
    -N noisy	Set the noisyness (MAKEVERBOSE) level of the build:
		    0	Quiet
		    1	Operations are described, commands are suppressed
		    2	Full output
		[Default: 2]
    -n          Show commands that would be executed, but do not execute them.
    -O obj      Set obj root directory to obj; sets a MAKEOBJDIR pattern.
                Unsets MAKEOBJDIRPREFIX.
    -o          Set MKOBJDIRS=no; do not create objdirs at start of build.
    -R release  Set RELEASEDIR to release.  [Default: releasedir]
    -r          Remove contents of TOOLDIR and DESTDIR before building.
    -T tools    Set TOOLDIR to tools.  If unset, and TOOLDIR is not set in
                the environment, nbmake will be (re)built unconditionally.
    -U          Set MKUNPRIVED=yes; build without requiring root privileges,
    		install from an UNPRIVED build with proper file permissions.
    -u          Set MKUPDATE=yes; do not run "make clean" first.
		Without this, everything is rebuilt, including the tools.
    -V v=[val]  Set variable `v' to `val'.
    -w wrapper  Create nbmake script as wrapper.
                [Default: ${TOOLDIR}/bin/nbmake-${MACHINE}]
    -X x11src   Set X11SRCDIR to x11src.  [Default: /usr/xsrc]
    -x          Set MKX11=yes; build X11R6 from X11SRCDIR
    -Z v        Unset ("zap") variable `v'. 

見られるように、いくつものスイッチで 標準構築の挙動を変更できて、その沢山は既に紹介済みで、 他は適切に設定できます。

31.7.4.make(1) variables used during build

いくつかの変数が NetBSD 構築の挙動を制御します。 他の方法で明示されていない限り、 これらの変数 may be set in either the process 環境 または、 in the MAKECONF で指定した make(1) 設定ファイル。 これらのオプションの definitive リストは、 toplevel ソースディレクトリーにある BUILDING および share/mk/bsd.README ファイル を御覧ください。

BUILDID

構築のための識別子。 識別子は object ディレクトリー名を appended し、そして コンパイラーフラグのような追加の構築 parameters をセットするために, make(1) 設定ファイルを can be consulted in 。

DESTDIR

構築された NetBSD システムを入れるディレクトリー。設定すると、 special options are passed to the compilation tools to prevent their default use of the ホストシステムの /usr/include/usr/lib 、うんぬん。このパス名は、 スラッシュ (/) character で終わるべきではありません ( システムのルートディレクトリーにインストールするには、 DESTDIR を空文字列に設定します)。 The ディレクトリー must reside on a ロングファイルネームおよびハードリンクをサポートしているファイルシステム。

USETOOLSyesなら Defaults は空文字列; その他は unset 。註: build.sh will provide a default (destdir.MACHINE in the top-level .OBJDIR) unless run in expert mode.

EXTERNAL_TOOLCHAIN

もしユーザーによって定義されていれば、 外部の toolchain のルート(例 /usr/local/gnu) を示します。これは default toolchain が利用可能でない時でさえ、 クロス構築 framework を enables します (下の TOOLCHAIN_MISSING を見てください)。

Default: Unset

MAKEVERBOSE

The verbosity of build messages. サポートしている values:

0 No descriptive messages are shown.
1 Descriptive messages are shown.
2 Descriptive messages are shown (prefixed with a '#') and command output is not suppressed.

Default: 2

MKCATPAGES

yes または no に設定できます。 構築中に、 preformatted プレーンテキスト manual pages を作るかどうかを 示します。

Default: yes

MKCRYPTO

yes または no に設定できます。 暗号法コードを構築物に入れるかどうかを示し; provided for the benefit of countries that do not allow strong cryptography. 標準・低セキュリティパスワード暗号化システム crypt(3) には影響しません。

Default: yes

MKDOC

yes または no に設定できます。構築中に DESTDIR/usr/share/doc 宛ての システム documentation をインストールするかどうかを示します。

Default: yes

MKHOSTOBJ

yes または no に設定できます。 yes に設定すると、 then for programs intended to be run on the compile host, the name, release and アーキテクチャー of the host オペレーティングシステム will be suffixed to the オブジェクトディレクトリー名 created by make obj. This allows for multiple host systems to compile NetBSD for a single target. no に設定すると、 then programs built to be run on the compile host will use the same オブジェクトディレクトリー名 as programs built to be run on the target.

Default: no

MKINFO

yes または no に設定できます。 ほとんどのコンパイルツールの documentation に利用されている、 GNU info ファイルを構築中に作成しインストールするかどうかを示します。

Default: yes

MKLINT

yes または no に設定できます。構築中に NetBSD ソースコードの一部に対し、 lint(1) を run するかどうかを示し、および、 DESTDIR/usr/libdata/lint に lint libraries をインストールするかどうかを示します。

Default: yes

MKMAN

yes または no に設定できます。 構築中 manual pages をインストールするかどうかを示します。

Default: yes

MKNLS

yes または no に設定できます。 構築中、 Native Language System locale zone files を コンパイルおよびインストールをするかどうかを示します。

Default: yes

MKOBJ

yes または no に設定できます。 make obj の running 時、オブジェクトディレクトリーが作られるかどうかを示します。 no に 設定すると、構築された全ファイルはソースツリーの内側に位置することになります。

Default: yes

MKPIC

yes または no に設定できます。 共有オブジェクトおよびライブラリーが構築中に作られ インストールされるかどうかを示します。 no に 設定すると、全構築物がスタティック(静的)リンクされます。

Default: プラットホームによります。これを書いている現在、 sh3 を除く全プラットホームでは default to yes

MKPICINSTALL

yes または no に設定できます。 共有ライブラリーの生成に使われる ar(1) format ライブラリー (lib*_pic.a) を構築中にインストールする かどうかを示します。

Default: yes

MKPROFILE

yes または no に設定できます。 構築中に、 profiled ライブラリー (lib*_p.a) を構築しインストールするかどうかを示します。

Default: yes; しかしながら、 いくつかのプラットホームでは toolchain の profiled コードの問題のため turn off MKPROFILE by default at times 。

MKSHARE

yes または no に設定できます。 構築中に、 ファイル destined to reside in DESTDIR/usr/share を構築しインストールするかどうなのかを示します。 no に 設定すると、 MKCATPAGESMKDOCMKINFOMKMAN および MKNLS の全てが無条件に no に 設定されます。

Default: yes

MKTTINTERP

yes または no に設定できます。 X の構築に、 decides if the TrueType バイトコード interpreter is turned on. 詳細は freetype.org を御覧ください。

Default: no

MKUNPRIVED

yes または no に設定できます。 unprivileged インストールをするかどうかを示します。ユーザー、グループ、 パーミッションおよびファイルフラグはインストールされた items にはセットされず; 代わりに、情報は DESTDIR 中に METALOG と呼ばれるファイルが appended されます。 METALOG の内容は 配布 tar ファイルの生成中に使われ、 適切なファイル ownership が蓄えられることを確実にします。

Default: no

MKUPDATE

yes または no に設定できます。 Indicates whether all install operations intended to write to DESTDIR will compare file timestamps before installing, and skip the install phase if the destination files are up-to-date. This also has implications on full builds ( 下を見てください)。

Default: no

MKX11

yes または no に設定できます。 X11SRCDIR から X11R6 を構築するかどうかを示します。

Default: yes

TOOLDIR

一度構築されたホストツールを hold するディレクトリー。このディレクトリーは should be unique to a given host system and NetBSD ソースツリー. (しかしながら、 multiple targets が同じ TOOLDIR を share するかも知れず; the target-依存 ファイルは have ユニークな名前をもっています)。 もし設定していないなら、 a default based on the uname(1) 情報 of the host プラットホーム will be created in the .OBJDIR of src.

Default: Unset.

USETOOLS

TOOLDIR で指定されたツールを構築中に一部分として使うかどうか を示します。クロスコンパイルには yes を設定しなければなりません。

yes TOOLDIR からのツールを使います。
no TOOLNAME からのツールを使いませんが、 but refuse to build native コンパイルツール components that are version-specific for that tool.
never native tool components の構築時でさえ TOOLNAME からのツールを使いません。 これは 伝統的 NetBSD 構築法に似ていますが、しかし、 用いられているコンパイルツールが ツリーの構築を成功されるのに十分に現代的か検証しません。 これは NetBSD ソースツリー全体を構築する時、 構築もしくは runtime 問題を引き起こすかもしれません。

Default: yes if building all or part of a whole NetBSD ソースツリー (detected automatically); no otherwise (to preserve traditional semantics of the bsd.*.mk make(1) include files).

X11SRCDIR

X11R6 ソースの入るディレクトリーです。 main X11R6 ソースは X11SRCDIR/xfree/xc にあります。

Default: usr/xsrc

次の変数 only affect the top level Makefile and do not affect manually building subtrees of the NetBSD ソースコード。

INSTALLWORLDDIR

make installworld ターゲットがインストールする位置。

Default: /

MKOBJDIRS

yes または no に設定できます。 構築開始時にオブジェクトディレクトリーが自動的に作られる (via a make obj pass) かどうかを示します。

Default: no

MKUPDATE

yes または no に設定できます。設定すると、 then addition to the effects described for MKUPDATE=yes above, this implies the effect of NOCLEANDIR (すなわち、 make cleandir が回避されます)。

Default: no

NOCLEANDIR

設定すると、 full build の make cleandir phase を回避します。 これは、ソースツリー内の変更されたファイルだけの再コンパイルを allowing する effect があります。これはツリー上のわずかなファイルだけが updating された時の構築をスピードアップできます。

Default: Unset

NODISTRIBDIRS

設定すると、 full build の make distrib-dirs を回避します。 This skips running mtree(8) on DESTDIR, useful on systems where building as an unprivileged user, or where it is known that the system wide mtree files have not changed.

Default: Unset

NOINCLUDES

設定すると、 full build の make includes phase を回避します。 This has the effect of preventing make(1) from thinking that some programs are out-of-date simply because system include files have changed. しかしながら、このオプション should not be trusted when updating the NetBSD ソースツリー全体 arbitrarily; その場合 MKUPDATE=yes を使うことを提案します。

Default: Unset

RELEASEDIR

設定すると、 make release の終わりに書かれる release(7) 配置位置 のディレクトリーを指定します。

Default: Unset

TOOLCHAIN_MISSING

in-tree toolchain で働くものがないプラットホーム上、あるいは、 native system toolchain (すなわち non-cross tools available via your シェルの検索パス)を使う事を 必要とする/要望するなら yes に設定します。

Default: target プラットホームによります; in-tree toolchain のプラットホームでは no に設定されています。