List known supported and obsolete mk.conf(5) variables,
so that searches in this document at least find them.
This partially reverts my revision 1.144 on 2023-06-12
which completely removed the duplication with mk.conf(5).
Remove quote characters from some section headings;
it makes it harder to search for a section by known name
when rendering in markup variations that use smart quotes.
Document that variables set in the environment or the
nbmake-MACHINE wrapper script don't override variable
assignments in mk.conf(5), and that using ?= in mk.conf
allows environment / nbmake-MACHINE variables to override
mk.conf.
Consistently refer to "nbmake-MACHINE wrapper script".
Set MAKECONF to mk.conf in the same directory as build.sh
(i.e., the top of the source tree) if mk.conf is present.
This means unprivileged users can benefit from mk.conf(5)
semantics without write privileges to /etc/mk.conf, and
also simplifies per-source-directory configuration.
Fail early if $MAKECONF is empty, since build.sh will fail
anyway after rebuilding nbmake.
Ensure that the computed MAKECONF isn't empty, and then
always set MAKECONF in the makewrapper (nbmake-$MACHINE).
Improve some formatting consistency in BUILDING.mdoc,
(even if BUILDING is generated without markup).
Remove all "make" variables / mk.conf(5) variables already documented
in mk.conf(5). The duplication was a maintenance headache, as I've
experienced over recent weeks getting the build documentation up to
date.
Add notes clarifying that manual page references are to the NetBSD
manual pages, not to the host manual pages, and how to format from
source, or find online at https://man.netbsd.org.
Add explicit links to the mdoc(7) in-tree source for mk.conf(5),
hier(7), and release(7) because those are directly relevant to the host
build information in BUILDING.
Note: We don't normally need these notes for native documentation,
but BUILDING is intended for users on host systems which might not
be NetBSD(-current).
Add missing defaults.
Sync variable entries from mk.conf(5).
Merge the "make variables for full builds" section into the previous.
Having two separate sections and some entries duplicated was confusing
when searching for variables.
The NBUILDJOBS option was deprecated in 2002;
there's no need to keep warning about it,
remove from params / show-params,
and only document as obsolete.
MKX11=yes wants MKINET6=yes
Change the width of the variable lists to 14n (from 15n)
so that when the lists are rendered and then left aligned,
the column is 16 characters (aka 2 tabs) which makes
copypasta to bsd.README easier.
Incorporate content and styles updates for mk.conf entries
from share/man/man5/mk.conf.5, which is the canonical
reference for mk.conf.
Add: BSDOBJDIR, BSDSRCDIR, EXTERNAL_TOOLCHAIN, MKDEBUGKERNEL,
MKDEBUGTOOLS, MKHTML, MKLINKLIB, MKOBJDIRS, TOOLCHAIN_MISSING,
NETBSDSRCDIR
It's for further study as to whether we just replace the
most of subsection "make" variables with a link to mk.conf(5).
Style:
- Add more .de macros per mk.conf.5.
- Order list items alphabetically. When multiple items are present
in a list item, sort within the item first.
- More cross-references.
doc/BUILDING.mdoc is the upstream for BUILDING, so add recent changes
in the latter to the former, formatting correctly.
Move INSTALLBOOT_UBOOT_PATHS to Environment variables.
Move INSTALLBOOT_BOARDS to "make" variables for full builds.
Add installboot(8) cross-reference.
The previous commit introduced the ability to install a set of
bootable images as a normal part of a release build. While this made
it easy to install bootable images, the contents of a release build
depend on whether or not U-Boot packages are installed in /usr/pkgsrc,
which is the default location searched by installboot(8).
This commit requires users to explicitly list the bootable images to
be installed, which by default is none (i.e., prior behavior).
Release builds for arm platforms create compressed images in
${RELEASEDIR}/${RELEASEMACHINEDIR}/binary/gzimg. However, in some
cases, e.g., armv7.img.gz, they are not bootable. Consequently, boot
blocks must be manually installed in the images, which is an extra
barrier for testing systems or adopting NetBSD. This has prompted
creation of external repositories, e.g., armbsd.org, to host a
collection of bootable images. However, this does not ease the burden
on developers compiling their own systems; for them, manual
installation of boot blocks is still required.
For arm platforms, etc/etc.evbarm/Makefile.inc contains the commands
used to create system images. Because installboot(8) can write boot
blocks directly to system images, a loop through possible boards can
create a series of bootable images during the normal build process.
In the case of many arm platforms, installboot(8) uses U-Boot boot
blocks, which are not part of the NetBSD source code. Developers can,
however, install as many U-Boot boot blocks as desired, either in the
default location of /usr/pkg/share/u-boot or in a set of directories
pointed to by the U-Boot search path, the INSTALLBOOT_UBOOT_PATHS
environment variable. For each board with an available boot block, a
board-specific bootable image will be created in
${RELEASEDIR}/${RELEASEMACHINEDIR}/binary/gzimg. If a boot block is
not available, which is the typical situation currently, no additional
image will be created.
This facility creates opportunities to build bootable images for any
number of boards within the scope of a standard release build.
However, that is not required and will not occur without the
intervention of installing U-Boot boot blocks prior to the build.
MKKDEBUG -> MKDEBUGKERNEL
MKTOOLSDEBUG -> MKDEBUGTOOLS
while keeping compatibility with the old names. Add missing documentation.
Now all debugging tunables are prefixed with MKDEBUG.
If it's yes, all local symbols of shared libraries are stripped
(default). If it's no, only temporary local symbols are stripped;
for example, symbols of static functions are kept. Keeping such
symbols is useful on using DTrace for userland libraries and
getting a backtrace from a rump server loading modules (shared
libraries).
Proposed and discussed on tech-kern and tech-toolchain
the support in the rest of the source tree.
X11 sets could use some cleaning up perhaps (just deletion, as
we've never really marked the old X11R6 as obsolete for native
xorg using platforms so far either.)
lukem