File:  [NetBSD Developer Wiki] / wikisrc / guide / build.mdwn
Revision 1.1: download - view: text, annotated - select for diffs
Tue Mar 5 23:58:28 2013 UTC (7 years, 7 months ago) by jdf
Branches: MAIN
CVS tags: HEAD
build Guide -> wiki

    1: # Crosscompiling NetBSD with build.sh
    2: 
    3: When targeting a product for an embedded platform, it's not feasible to have all 
    4: the development tools available on that same platform. Instead, some method of 
    5: crosscompiling is usually used today. NetBSD 1.6 and forward comes with a 
    6: framework to build both the operating system's kernel and the whole userland for 
    7: either the same platform that the compiler runs on, or for a different platform, 
    8: using crosscompiling. Crosscompiling requires assembler, linker, compiler etc. 
    9: to be available and built for the target platform. The new build scheme will 
   10: take care of creating these tools for a given platform, and make them available 
   11: ready to use to do development work.
   12: 
   13: In this chapter, we will show how to use `build.sh` to first create a 
   14: crosscompiling toolchain, including cross-compiler, cross-assembler, 
   15: cross-linker and so on. While native kernel builds are covered in [[Compiling 
   16: the kernel|guide/kernel]], these tools are then used to manually configure and 
   17: crosscompile a kernel for a different platform, and then show how to use 
   18: `build.sh` as a convenient alternative. After that works, the whole NetBSD 
   19: userland will be compiled and packed up in the format of a NetBSD release. In 
   20: the examples, we will use the Sun UltraSPARC (*sparc64*) 64-bit platform as 
   21: target platform, any other platform supported by NetBSD can be targetted as well 
   22: specifying its name (see `/usr/src/sys/arch`).
   23: 
   24: Before starting, take note that it is assumed that the NetBSD sources from the 
   25: `netbsd-4-0` branch are available in `/usr/src` as described in
   26: [[Obtaining the sources|guide/fetch]].
   27: 
   28: A more detailed description of the `build.sh` framework can be found in Luke 
   29: Mewburn and Matthew Green's 
   30: [paper](http://www.mewburn.net/luke/papers/build.sh.pdf) and their 
   31: [presentation](http://www.mewburn.net/luke/talks/bsdcon-2003/index.html) from 
   32: BSDCon 2003 as well as in `/usr/src/BUILDING`.
   33: 
   34: ## Building the crosscompiler
   35: 
   36: The first step to do cross-development is to get all the necessary tools 
   37: available. In NetBSD terminology, this is called the "toolchain", and it 
   38: includes BSD-compatible
   39: [make(1)](http://netbsd.gw.com/cgi-bin/man-cgi?make+1+NetBSD-current),
   40: C/C++ compilers, linker, assembler, 
   41: [config(8)](http://netbsd.gw.com/cgi-bin/man-cgi?config+8+NetBSD-current), 
   42: as well as a fair number of tools that are only required when crosscompiling a 
   43: full NetBSD release, which we won't cover here.
   44: 
   45: The command to create the crosscompiler is quite simple, using NetBSD's new 
   46: `src/build.sh` script. Please note that all the commands here can be run as 
   47: normal (non-root) user:
   48: 
   49:     $ cd /usr/src
   50:     $ ./build.sh -m sparc64 tools
   51: 
   52: Make sure that the directory `/usr/obj` does exist, or add a `-O` option to the 
   53: build.sh call, redirecting the object directory someplace else.
   54: 
   55: If the tools have been built previously and they only need updated, then the 
   56: update option `-u` can be used to only rebuild tools that have changed:
   57: 
   58:     $ ./build.sh -u -m sparc64 tools
   59: 
   60: When the tools are built, information about them and several environment 
   61: variables is printed out:
   62: 
   63:     ...
   64:     ===> build.sh started: Thu Dec  2 22:18:11 CET 2007
   65:     ===> build.sh ended:   Thu Dec  2 22:28:22 CET 2007
   66:     ===> Summary of results:
   67:              build.sh command: ./build.sh -m sparc64 tools
   68:              build.sh started: Thu Dec  2 22:18:11 CET 2007
   69:              No nonexistent/bin/nbmake, needs building.
   70:              Bootstrapping nbmake
   71:              MACHINE:          sparc64
   72:              MACHINE_ARCH:     sparc64
   73:              TOOLDIR path:     /usr/src/tooldir.NetBSD-4.0-i386
   74:              DESTDIR path:     /usr/src/destdir.sparc64
   75:              RELEASEDIR path:  /usr/src/releasedir
   76:              Created /usr/src/tooldir.NetBSD-4.0-i386/bin/nbmake
   77:              makewrapper:      /usr/src/tooldir.NetBSD-4.0-i386/bin/nbmake-sparc64
   78:              Updated /usr/src/tooldir.NetBSD-4.0-i386/bin/nbmake-sparc64
   79:              Tools built to /usr/src/tooldir.NetBSD-4.0-i386
   80:              build.sh started: Thu Dec  2 22:18:11 CET 2007
   81:              build.sh ended:   Thu Dec  2 22:28:22 CET 2007
   82:     ===> . 
   83: 
   84: During the build, object directories are used consistently, i.e. special 
   85: directories are kept that keep the platform-specific object files and compile 
   86: results. In our example, they will be kept in directories named `obj.sparc64` as 
   87: we build for UltraSPARC as target platform.
   88: 
   89: The toolchain itself is part of this, but as it's hosted and compiled for a i386 
   90: system, it will get placed in its own directory indicating where to cross-build 
   91: from. Here's where our crosscompiler tools are located:
   92: 
   93:     $ pwd
   94:     /usr/src
   95:     $ ls -d tooldir.*
   96:     tooldir.NetBSD-4.0-i386
   97: 
   98: So the general rule of thumb is for a given `host` and `target` system 
   99: combination, the crosscompiler will be placed in the `src/tooldir.host` 
  100: directory by default. A full list of all tools created for crosscompiling the 
  101: whole NetBSD operating system includes:
  102: 
  103:     $ ls tooldir.NetBSD-4.0-i386/bin/
  104:     nbasn1_compile          nbmakefs                nbzic
  105:     nbcap_mkdb              nbmakeinfo              sparc64--netbsd-addr2li
  106:     nbcat                   nbmakewhatis            sparc64--netbsd-ar
  107:     nbcksum                 nbmenuc                 sparc64--netbsd-as
  108:     nbcompile_et            nbmkcsmapper            sparc64--netbsd-c++
  109:     nbconfig                nbmkdep                 sparc64--netbsd-c++filt
  110:     nbcrunchgen             nbmkesdb                sparc64--netbsd-cpp
  111:     nbctags                 nbmklocale              sparc64--netbsd-dbsym
  112:     nbdb                    nbmknod                 sparc64--netbsd-g++
  113:     nbeqn                   nbmktemp                sparc64--netbsd-g77
  114:     nbfgen                  nbmsgc                  sparc64--netbsd-gcc
  115:     nbfile                  nbmtree                 sparc64--netbsd-gcc-3.3
  116:     nbgencat                nbnroff                 sparc64--netbsd-gccbug
  117:     nbgroff                 nbpax                   sparc64--netbsd-gcov
  118:     nbhexdump               nbpic                   sparc64--netbsd-ld
  119:     nbhost-mkdep            nbpwd_mkdb              sparc64--netbsd-lint
  120:     nbindxbib               nbrefer                 sparc64--netbsd-mdsetim
  121:     nbinfo                  nbrpcgen                sparc64--netbsd-nm
  122:     nbinfokey               nbsoelim                sparc64--netbsd-objcopy
  123:     nbinstall               nbstat                  sparc64--netbsd-objdump
  124:     nbinstall-info          nbsunlabel              sparc64--netbsd-ranlib
  125:     nbinstallboot           nbtbl                   sparc64--netbsd-readelf
  126:     nblex                   nbtexi2dvi              sparc64--netbsd-size
  127:     nblorder                nbtexindex              sparc64--netbsd-strings
  128:     nbm4                    nbtsort                 sparc64--netbsd-strip
  129:     nbmake                  nbuudecode
  130:     nbmake-sparc64          nbyacc 
  131: 
  132: As you can see, most of the tools that are available native on NetBSD are 
  133: present with some program prefix to identify the target platform for tools that 
  134: are specific to a certain target platform.
  135: 
  136: One important tool that should be pointed out here is `nbmake-sparc64`. This is 
  137: a shell wrapper for a BSD compatible 
  138: [make(1)](http://netbsd.gw.com/cgi-bin/man-cgi?make+1+NetBSD-5.0.1+i386) command 
  139: that's setup to use all the right commands from the crosscompiler toolchain. 
  140: Using this wrapper instead of `/usr/bin/make` allows crosscompiling programs 
  141: that were written using the NetBSD Makefile infrastructure (see `src/share/mk`). 
  142: We will use this 
  143: [make(1)](http://netbsd.gw.com/cgi-bin/man-cgi?make+1+NetBSD-5.0.1+i386) wrapper 
  144: in a second to cross compile the kernel!
  145: 
  146: ## Configuring the kernel manually
  147: 
  148: Now that we have a working crosscompiler available, the "usual" steps for 
  149: building a kernel are needed - create a kernel config file, run 
  150: [config(1)](http://netbsd.gw.com/cgi-bin/man-cgi?config+1+NetBSD-5.0.1+i386), 
  151: then build. As the 
  152: [config(1)](http://netbsd.gw.com/cgi-bin/man-cgi?config+1+NetBSD-5.0.1+i386) 
  153: program used to create header files and Makefile for a kernel build is platform 
  154: specific, we need to use the `nbconfig` program that's part of our new 
  155: toolchain. That aside, the procedure is just as like compiling a "native" NetBSD 
  156: kernel. Commands involved here are:
  157: 
  158:     $ cd /usr/src/sys/arch/sparc64/conf
  159:     $ cp GENERIC MYKERNEL
  160:     $ vi MYKERNEL
  161:     $ /usr/src/tooldir.NetBSD-4.0-i386/bin/nbconfig MYKERNEL
  162: 
  163: That's all. This command has created a directory `../compile/MYKERNEL` with a 
  164: number of header files defining information about devices to compile into the 
  165: kernel, a Makefile that is setup to build all the needed files for the kernel, 
  166: and link them together.
  167: 
  168: ## Crosscompiling the kernel manually
  169: 
  170: We have all the files and tools available to crosscompile our UltraSPARC-based 
  171: kernel from our Intel-based host system, so let's get to it! After changing in 
  172: the directory created in the previous step, we need to use the crosscompiler 
  173: toolchain's `nbmake-sparc64` shell wrapper, which just calls make(1) with all 
  174: the necessary settings for crosscompiling for a sparc64 platform:
  175: 
  176:     $ cd ../compile/MYKERNEL/
  177:     $ /usr/src/tooldir.NetBSD-4.0-i386/bin/nbmake-sparc64 depend
  178:     $ /usr/src/tooldir.NetBSD-4.0-i386/bin/nbmake-sparc64
  179: 
  180: This will churn away a bit, then spit out a kernel:
  181: 
  182:     ...
  183:        text    data     bss     dec     hex filename
  184:     5016899  163728  628752 5809379  58a4e3 netbsd
  185:     $ ls -l netbsd
  186:     -rwxr-xr-x  1 feyrer  666  5874663 Dec  2 23:17 netbsd
  187:     $ file netbsd
  188:     netbsd: ELF 64-bit MSB executable, SPARC V9, version 1 (SYSV), statically linked, not stripped 
  189: 
  190: Now the kernel in the file `netbsd` can either be transferred to a UltraSPARC 
  191: machine (via NFS, FTP, scp, etc.) and booted from a possible harddisk, or 
  192: directly from our cross-development machine using NFS.
  193: 
  194: After configuring and crosscompiling the kernel, the next logical step is to 
  195: crosscompile the whole system, and bring it into a distribution-ready format. 
  196: Before doing so, an alternative approach to crosscompiling a kernel will be 
  197: shown in the next section, using the `build.sh` script to do configuration and 
  198: crosscompilation of the kernel in one step.
  199: 
  200: ## Crosscompiling the kernel with build.sh
  201: 
  202: A cross compiled kernel can be done manually as described in the previous 
  203: sections, or by the easier method of using `build.sh`, which will be shown here.
  204: 
  205: Preparation of the kernel config file is the same as described above:
  206: 
  207:     $ cd /usr/src/sys/arch/sparc64/conf
  208:     $ cp GENERIC MYKERNEL
  209:     $ vi MYKERNEL 
  210: 
  211: Then edit `MYKERNEL` and once finished, all that needs to be done is to use 
  212: `build.sh` to build the kernel (it will also configure it, running the steps 
  213: shown above):
  214: 
  215:     $ cd /usr/src
  216:     $ ./build.sh -u -m sparc64 kernel=MYKERNEL
  217: 
  218: Notice that update (`-u`) was specified, the tools are already built, there is 
  219: no reason to rebuild all of the tools. Once the kernel is built, `build.sh` will 
  220: print out the location of it along with other information:
  221: 
  222:     ...
  223:     ===> Summary of results:
  224:              build.sh command: ./build.sh -u -m sparc64 kernel=MYKERNEL
  225:              build.sh started: Thu Dec  2 23:30:02 CET 2007
  226:              No nonexistent/bin/nbmake, needs building.
  227:              Bootstrapping nbmake
  228:              MACHINE:          sparc64
  229:              MACHINE_ARCH:     sparc64
  230:              TOOLDIR path:     /usr/src/tooldir.NetBSD-4.0-i386
  231:              DESTDIR path:     /usr/src/destdir.sparc64
  232:              RELEASEDIR path:  /usr/src/releasedir
  233:              Created /usr/src/tooldir.NetBSD-4.0-i386/bin/nbmake
  234:              makewrapper:      /usr/src/tooldir.NetBSD-4.0-i386/bin/nbmake-sparc64
  235:              Updated /usr/src/tooldir.NetBSD-4.0-i386/bin/nbmake-sparc64
  236:              Building kernel without building new tools
  237:              Building kernel:  MYKERNEL
  238:              Build directory:  /usr/src/sys/arch/sparc64/compile/obj.sparc64/GENERIC
  239:              Kernels built from MYKERNEL:
  240:               /usr/src/sys/arch/sparc64/compile/obj.sparc64/MYKERNEL/netbsd
  241:              build.sh started: Thu Dec  2 23:30:02 CET 2007
  242:              build.sh ended:   Thu Dec  2 23:38:22 CET 2007
  243:     ===> . 
  244: 
  245: The path to the kernel built is of interest here: 
  246: `/usr/src/sys/arch/sparc64/compile/obj.sparc64/MYKERNEL/netbsd`, it can be used 
  247: the same way as described above.
  248: 
  249: ## Crosscompiling the userland
  250: 
  251: By now it is probably becoming clear that the toolchain actually works in 
  252: stages. First the crosscompiler is built, then a kernel. Since `build.sh` will 
  253: attempt to rebuild the tools at every invocation, using `update` saves time. It 
  254: is probably also clear that outside of a few options, the `build.sh` semantics 
  255: are basically `build.sh command`. So, it stands to reason that building the 
  256: whole userland and/or a release is a matter of using the right commands.
  257: 
  258: It should be no surprise that building and creating a release would look like 
  259: the following:
  260: 
  261:     $ ./build.sh -U -u -m sparc64 release
  262: 
  263: These commands will compile the full NetBSD userland and put it into a 
  264: destination directory, and then build a release from it in a release directory. 
  265: The `-U` switch is added here for an *unprivileged* build, i.e. one that's 
  266: running as normal user and not as root. As no further switches to `build.sh` 
  267: were given nor any environment variables were set, the defaults of 
  268: `DESTDIR=/usr/src/destdir.sparc64` and `RELEASEDIR=/usr/src/releasedir` are 
  269: used, as shown in the `build.sh`-output above.
  270: 
  271: ## Crosscompiling the X Window System
  272: 
  273: The NetBSD project has its own copy of the X Window System's source which is 
  274: currently based on XFree86 version 4, and which contains changes to make X going 
  275: on as many of the platforms supported by NetBSD as possible. Due to this, it is 
  276: desirable to use the X Window System version available from and for NetBSD, 
  277: which can also be crosscompiled much like the kernel and base system. To do so, 
  278: the xsrc sources must be checked out from CVS into `/usr/xsrc` just as src 
  279: and pkgsrc were as described in [[Obtaining the sources|guide/fetch]].
  280: 
  281: After this, X can be crosscompiled for the target platform by adding the `-x` 
  282: switch to build.sh, e.g. when creating a full release:
  283: 
  284:     $ ./build.sh -U -x -u -m sparc64 release
  285: 
  286: The `-U` flag for doing unprivileged (non-root) builds and the `-u` flag for not 
  287: removing old files before building as well as the `-m arch` option to define the 
  288: target architecture have already been introduced, and the `-x` option to also 
  289: (cross)compile xsrc is another option.
  290: 
  291: ## Changing build behaviour
  292: 
  293: Similar to the old, manual building method, the new toolchain has a lot of 
  294: variables that can be used to direct things like where certain files go, what 
  295: (if any) tools are used and so on. A look in `src/BUILDING` covers most of them. 
  296: In this section some examples of changing default settings are given, each 
  297: following its own ways.
  298: 
  299: ### Changing the Destination Directory
  300: 
  301: Many people like to track NetBSD-current and perform cross compiles of 
  302: architectures that they use. The logic for this is simple, sometimes a new 
  303: feature or device becomes available and someone may wish to use it. By keeping 
  304: track of changes and building every now and again, one can be assured that these 
  305: architectures can build their own release.
  306: 
  307: It is reasonable to assume that if one is tracking and building for more than 
  308: one architecture, they might want to keep the builds in a different location 
  309: than the default. There are two ways to go about this, either use a script to 
  310: set the new DESTDIR, or simply do so interactively. In any case, it can be set 
  311: the same way as any other variable (depending on your shell of course).
  312: 
  313: For bash, the Bourne or Korn shell, this is:
  314: 
  315:     $ export DESTDIR=/usr/builds/sparc64
  316: 
  317: For tcsh and the C shell, the command is:
  318: 
  319:     $ setenv DESTDIR /usr/builds/sparc64
  320: 
  321: Simple enough. When the build is run, the binaries and files will be sent to 
  322: `/usr/builds`.
  323: 
  324: ### Static Builds
  325: 
  326: The NetBSD toolchain builds and links against shared libraries by default. Many 
  327: users still prefer to be able to link statically. Sometimes a small system can 
  328: be created without having shared libraries, which is a good example of doing a 
  329: full static build. If a particular build machine will always need one 
  330: environment variable set in a particular way, then it is easiest to simply add 
  331: the changed setting to `/etc/mk.conf`.
  332: 
  333: To make sure a build box always builds statically, simply add the following line 
  334: to `/etc/mk.conf`:
  335: 
  336:     LDSTATIC=-static
  337: 
  338: ### Using build.sh options
  339: 
  340: Besides variables in environment and `/etc/mk.conf`, the build process can be 
  341: influenced by a number of switches to the `build.sh` script itself, as we have 
  342: already seen when forcing unprivileged (non-root) builds, selecting the target 
  343: architecture or preventing deletion of old files before the build. All these 
  344: options can be listed by running `build.sh -h`:
  345: 
  346:     $ cd /usr/src
  347:     $ build.sh -h
  348:     Usage: build.sh [-EnorUux] [-a arch] [-B buildid] [-D dest] [-j njob]
  349:             [-M obj] [-m mach] [-N noisy] [-O obj] [-R release] [-T tools]
  350:             [-V var=[value]] [-w wrapper] [-X x11src] [-Z var]
  351:             operation [...]
  352:     
  353:      Build operations (all imply "obj" and "tools"):
  354:         build               Run "make build".
  355:         distribution        Run "make distribution" (includes DESTDIR/etc/ files).
  356:         release             Run "make release" (includes kernels and distrib media).
  357:     
  358:      Other operations:
  359:         help                Show this message and exit.
  360:         makewrapper         Create nbmake-${MACHINE} wrapper and nbmake.
  361:                             Always performed.
  362:         obj                 Run "make obj".  [Default unless -o is used]
  363:         tools               Build and install tools.
  364:         install=idir        Run "make installworld" to `idir' to install all sets
  365:                 except `etc'.  Useful after "distribution" or "release"
  366:         kernel=conf         Build kernel with config file `conf'
  367:         releasekernel=conf  Install kernel built by kernel=conf to RELEASEDIR.
  368:         sets                Create binary sets in RELEASEDIR/MACHINE/binary/sets.
  369:                 DESTDIR should be populated beforehand.
  370:         sourcesets          Create source sets in RELEASEDIR/source/sets.
  371:         params              Display various make(1) parameters.
  372:     
  373:      Options:
  374:         -a arch     Set MACHINE_ARCH to arch.  [Default: deduced from MACHINE]
  375:         -B buildId  Set BUILDID to buildId.
  376:         -D dest     Set DESTDIR to dest.  [Default: destdir.MACHINE]
  377:         -E          Set "expert" mode; disables various safety checks.
  378:                     Should not be used without expert knowledge of the build system.
  379:         -j njob     Run up to njob jobs in parallel; see make(1) -j.
  380:         -M obj      Set obj root directory to obj; sets MAKEOBJDIRPREFIX.
  381:                     Unsets MAKEOBJDIR.
  382:         -m mach     Set MACHINE to mach; not required if NetBSD native.
  383:         -N noisy    Set the noisyness (MAKEVERBOSE) level of the build:
  384:                 0   Quiet
  385:                 1   Operations are described, commands are suppressed
  386:                 2   Full output
  387:             [Default: 2]
  388:         -n          Show commands that would be executed, but do not execute them.
  389:         -O obj      Set obj root directory to obj; sets a MAKEOBJDIR pattern.
  390:                     Unsets MAKEOBJDIRPREFIX.
  391:         -o          Set MKOBJDIRS=no; do not create objdirs at start of build.
  392:         -R release  Set RELEASEDIR to release.  [Default: releasedir]
  393:         -r          Remove contents of TOOLDIR and DESTDIR before building.
  394:         -T tools    Set TOOLDIR to tools.  If unset, and TOOLDIR is not set in
  395:                     the environment, nbmake will be (re)built unconditionally.
  396:         -U          Set MKUNPRIVED=yes; build without requiring root privileges,
  397:                 install from an UNPRIVED build with proper file permissions.
  398:         -u          Set MKUPDATE=yes; do not run "make clean" first.
  399:             Without this, everything is rebuilt, including the tools.
  400:         -V v=[val]  Set variable `v' to `val'.
  401:         -w wrapper  Create nbmake script as wrapper.
  402:                     [Default: ${TOOLDIR}/bin/nbmake-${MACHINE}]
  403:         -X x11src   Set X11SRCDIR to x11src.  [Default: /usr/xsrc]
  404:         -x          Set MKX11=yes; build X11R6 from X11SRCDIR
  405:         -Z v        Unset ("zap") variable `v'. 
  406: 
  407: As can be seen, a number of switches can be set to change the standard build 
  408: behaviour. A number of them has already been introduced, others can be set as 
  409: appropriate.
  410: 
  411: ### make(1) variables used during build
  412: 
  413: Several variables control the behaviour of NetBSD builds. Unless otherwise 
  414: specified, these variables may be set in either the process environment or in 
  415: the [make(1)](http://netbsd.gw.com/cgi-bin/man-cgi?make+1+NetBSD-5.0.1+i386) 
  416: configuration file specified by `MAKECONF`. For a definitive list of these 
  417: options, see `BUILDING` and `share/mk/bsd.README` files in the toplevel source 
  418: directory.
  419: 
  420:  * *BUILDID* -- Identifier for the build. The identifier will be appended to 
  421:    object directory names, and can be consulted in the 
  422:    [make(1)](http://netbsd.gw.com/cgi-bin/man-cgi?make+1+NetBSD-5.0.1+i386) 
  423:    configuration file in order to set additional build parameters, such as 
  424:    compiler flags.
  425: 
  426:  * *DESTDIR* -- Directory to contain the built NetBSD system. If set, special 
  427:    options are passed to the compilation tools to prevent their default use of 
  428:    the host system's `/usr/include`, `/usr/lib`, and so forth. This pathname 
  429:    should not end with a slash (/) character (For installation into the system's 
  430:    root directory, set `DESTDIR` to an empty string). The directory must reside 
  431:    on a filesystem which supports long filenames and hard links.
  432: 
  433:    Defaults to an empty string if `USETOOLS` is `yes`; unset otherwise. Note: 
  434:    `build.sh` will provide a default (destdir.MACHINE in the top-level 
  435:    `.OBJDIR`) unless run in `expert` mode.
  436: 
  437:  * *EXTERNAL\_TOOLCHAIN* -- If defined by the user, points to the root of an 
  438:    external toolchain (e.g. `/usr/local/gnu`). This enables the cross-build 
  439:    framework even when default toolchain is not available (see 
  440:    `TOOLCHAIN_MISSING` below).
  441: 
  442:    Default: Unset
  443: 
  444:  * *MAKEVERBOSE* -- The verbosity of build messages. Supported values:
  445: 
  446:     * `0` -- No descriptive messages are shown.
  447:     * `1` -- Descriptive messages are shown.
  448: 	* `2` -- Descriptive messages are shown (prefixed with a '\#') and command 
  449: 	  output is not suppressed.
  450:    
  451:    Default: 2
  452: 
  453:  * *MKCATPAGES* -- Can be set to `yes` or `no`. Indicates whether preformatted 
  454:    plaintext manual pages will be created during a build.
  455: 
  456:    Default: `yes`
  457: 
  458:  * *MKCRYPTO* -- Can be set to `yes` or `no`. Indicates whether cryptographic 
  459:    code will be included in a build; provided for the benefit of countries that 
  460:    do not allow strong cryptography. Will not affect the standard low-security 
  461:    password encryption system, 
  462:    [crypt(3)](http://netbsd.gw.com/cgi-bin/man-cgi?crypt+3+NetBSD-5.0.1+i386).
  463: 
  464:    Default: `yes`
  465: 
  466:  * *MKDOC* -- Can be set to `yes` or `no`. Indicates whether system 
  467:    documentation destined for `DESTDIR``/usr/share/doc` will be installed during 
  468:    a build.
  469: 
  470:    Default: `yes`
  471: 
  472:  * *MKHOSTOBJ* -- Can be set to `yes` or `no`. If set to `yes`, then for 
  473:    programs intended to be run on the compile host, the name, release and 
  474:    architecture of the host operating system will be suffixed to the name of the 
  475:    object directory created by `make obj`. This allows for multiple host systems 
  476:    to compile NetBSD for a single target. If set to `no`, then programs built to 
  477:    be run on the compile host will use the same object directory names as 
  478:    programs built to be run on the target.
  479: 
  480:    Default: `no`
  481: 
  482:  * *MKINFO* -- Can be set to `yes` or `no`. Indicates whether GNU info files, 
  483:    used for the documentation of most of the compilation tools, will be created 
  484:    and installed during a build.
  485: 
  486:    Default: `yes`
  487: 
  488:  * *MKLINT* -- Can be set to `yes` or `no`. Indicates whether 
  489:    [lint(1)](http://netbsd.gw.com/cgi-bin/man-cgi?lint+1+NetBSD-5.0.1+i386) will 
  490:    be run against portions of the NetBSD source code during the build, and 
  491:    whether lint libraries will be installed into `DESTDIR``/usr/libdata/lint`
  492: 
  493:    Default: `yes`
  494: 
  495:  * *MKMAN* -- Can be set to `yes` or `no`. Indicates whether manual pages will 
  496:    be installed during a build.
  497: 
  498:    Default: `yes`
  499: 
  500:  * *MKNLS* -- Can be set to `yes` or `no`. Indicates whether Native Language 
  501:    System locale zone files will be compiled and installed during a build.
  502: 
  503:    Default: `yes`
  504: 
  505:  * *MKOBJ* -- Can be set to `yes` or `no`. Indicates whether object directories 
  506:    will be created when running `make obj`. If set to `no`, then all built files 
  507:    will be located inside the regular source tree.
  508: 
  509:    Default: `yes`
  510: 
  511:  * *MKPIC* -- Can be set to `yes` or `no`. Indicates whether shared objects and 
  512:    libraries will be created and installed during a build. If set to `no`, the 
  513:    entire build will be statically linked.
  514: 
  515:    Default: Platform dependent. As of this writing, all platforms except sh3 default to `yes`
  516: 
  517:  * *MKPICINSTALL* -- Can be set to `yes` or `no`. Indicates whether the 
  518:    [ar(1)](http://netbsd.gw.com/cgi-bin/man-cgi?ar+1+NetBSD-5.0.1+i386) format 
  519:    libraries (`lib*_pic.a`), used to generate shared libraries, are installed 
  520:    during a build.
  521: 
  522:    Default: `yes`
  523: 
  524:  * *MKPROFILE* -- Can be set to `yes` or `no`. Indicates whether profiled 
  525:    libraries (`lib*_p.a`) will be built and installed during a build.
  526: 
  527:    Default: `yes`; however, some platforms turn off `MKPROFILE` by default at 
  528:    times due to toolchain problems with profiled code.
  529: 
  530:  * *MKSHARE* -- Can be set to `yes` or `no`. Indicates whether files destined to 
  531:    reside in `DESTDIR/usr/share` will be built and installed during a build. 
  532:    If set to `no`, then all of `MKCATPAGES`, `MKDOC`, `MKINFO`, `MKMAN` and 
  533:    `MKNLS` will be set to `no` unconditionally.
  534: 
  535:    Default: `yes`
  536: 
  537:  * *MKTTINTERP* -- Can be set to `yes` or `no`. For X builds, decides if the 
  538:    TrueType bytecode interpreter is turned on. See 
  539:    [freetype.org](http://freetype.org/patents.html) for details.
  540: 
  541:    Default: `no`
  542: 
  543:  * *MKUNPRIVED* -- Can be set to `yes` or `no`. Indicates whether an 
  544:    unprivileged install will occur. The user, group, permissions and file flags 
  545:    will not be set on the installed items; instead the information will be 
  546:    appended to a file called `METALOG` in `DESTDIR`. The contents of `METALOG` 
  547:    are used during the generation of the distribution tar files to ensure that 
  548:    the appropriate file ownership is stored.
  549: 
  550:    Default:  `no`
  551: 
  552:  * *MKUPDATE* -- Can be set to `yes` or `no`. Indicates whether all install 
  553:    operations intended to write to `DESTDIR` will compare file timestamps before 
  554:    installing, and skip the install phase if the destination files are 
  555:    up-to-date. This also has implications on full builds (See below).
  556: 
  557:    Default: `no`
  558: 
  559:  * *MKX11* -- Can be set to `yes` or `no`. Indicates whether X11R6 is built from 
  560:    `X11SRCDIR`.
  561: 
  562:    Default: `yes`
  563: 
  564:  * *TOOLDIR* -- Directory to hold the host tools, once built. This directory 
  565:    should be unique to a given host system and NetBSD source tree. (However, 
  566:    multiple targets may share the same `TOOLDIR`; the target-dependent files 
  567:    have unique names). If unset, a default based on the 
  568:    [uname(1)](http://netbsd.gw.com/cgi-bin/man-cgi?uname+1+NetBSD-5.0.1+i386) 
  569:    information of the host platform will be created in the `.OBJDIR` of `src`.
  570: 
  571:    Default: Unset.
  572: 
  573:  * *USETOOLS* -- Indicates whether the tools specified by `TOOLDIR` should be 
  574:    used as part of a build in progress. Must be set to `yes` if cross-compiling.
  575: 
  576:     * `yes` -- Use the tools from `TOOLDIR`.
  577: 	* `no` -- Do not use the tools from `TOOLNAME`, but refuse to build native 
  578: 	  compilation tool components that are version-specific for that tool.
  579: 	* `never` -- Do not use the tools from `TOOLNAME`, even when building native 
  580: 	  tool components. This is similar to the traditional NetBSD build method, 
  581: 	  but does not verify that the compilation tools in use are up-to-date 
  582: 	  enough in order to build the tree successfully. This may cause build or 
  583: 	  runtime problems when building the whole NetBSD source tree.
  584: 
  585:    Default: `yes` if building all or part of a whole NetBSD source tree 
  586:    (detected automatically); `no` otherwise (to preserve traditional semantics 
  587:    of the `bsd.*.mk` 
  588:    [make(1)](http://netbsd.gw.com/cgi-bin/man-cgi?make+1+NetBSD-5.0.1+i386) 
  589:    include files).
  590: 
  591:  * *X11SRCDIR* -- Directory containing the X11R6 source. The main X11R6 source 
  592:    is found in `X11SRCDIR/xfree/xc`.
  593: 
  594:    Default: `usr/xsrc`
  595: 
  596: The following variables only affect the top level `Makefile` and do not affect 
  597: manually building subtrees of the NetBSD source code.
  598: 
  599:  * *INSTALLWORLDDIR* -- Location for the `make installworld` target to install 
  600:    to.
  601: 
  602:    Default: `/`
  603: 
  604:  * *MKOBJDIRS* -- Can be set to `yes` or `no`. Indicates whether object 
  605:    directories will be created automatically (via a `make obj` pass) at the 
  606:    start of a build.
  607: 
  608:    Default: `no`
  609: 
  610:  * *MKUPDATE* -- Can be set to `yes` or `no`. If set, then addition to the 
  611:    effects described for `MKUPDATE=yes` above, this implies the effect of 
  612:    `NOCLEANDIR` (i.e., `make cleandir` is avoided).
  613: 
  614:    Default: `no`
  615: 
  616:  * *NOCLEANDIR* -- If set, avoids the `make cleandir` phase of a full build. 
  617:    This has the effect of allowing only changed files in a source tree to 
  618:    recompiled. This can speed up builds when updating only a few files in the 
  619:    tree.
  620: 
  621:    Default: Unset
  622: 
  623:  * *NODISTRIBDIRS* -- If set, avoids the `make distrib-dirs` of a full build. 
  624:    This skips running 
  625:    [mtree(8)](http://netbsd.gw.com/cgi-bin/man-cgi?mtree+8+NetBSD-5.0.1+i386) on 
  626:    `DESTDIR`, useful on systems where building as an unprivileged user, or where 
  627:    it is known that the system wide mtree files have not changed.
  628: 
  629:    Default: Unset
  630: 
  631:  * *NOINCLUDES* -- If set, avoids the `make includes` phase of a full build. 
  632:    This has the effect of preventing 
  633:    [make(1)](http://netbsd.gw.com/cgi-bin/man-cgi?make+1+NetBSD-5.0.1+i386) from 
  634:    thinking that some programs are out-of-date simply because system include 
  635:    files have changed. However, this option should not be trusted when updating 
  636:    the entire NetBSD source tree arbitrarily; it is suggested to use 
  637:    `MKUPDATE=yes` in that case.
  638: 
  639:    Default: Unset
  640: 
  641:  * *RELEASEDIR* -- If set, specifies the directory to which a 
  642:    [release(7)](http://netbsd.gw.com/cgi-bin/man-cgi?release+7+NetBSD-5.0.1+i386) 
  643:    layout will be written at the end of a `make release`.
  644: 
  645:    Default: Unset
  646: 
  647:  * *TOOLCHAIN\_MISSING* -- Set to `yes` on platforms for which there is no 
  648:    working in-tree toolchain, or if you need/wish using native system toolchain 
  649:    (i.e. non-cross tools available via your shell search path).
  650: 
  651:    Default: depends on target platform; on platforms with in-tree toolchain is set to `no`.
  652: 

CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb