Use UPPERCASE as the convention to describe an option argument,
as it's more noticable than lowercase in the help description.
Expand tabs in the help.
Editorial improvements.
Remove support for building extsrc/:
1. Makefile: remove do-extsrc target.
2. build.sh: remove options -y and -Y extsrcdir.
3. distrib/sets: remove support for extsrc in various tools
including the options -L ext and -y, and the extsrc sets.
4. doc/BUILDING.mdoc: remove docs for extsrc/, EXTSRCSRCDIR, MKEXTSRC (etc)
5. bsd.own.mk and various Makefiles: remove support for extsrc/,
EXTSRCSRCDIR, MKEXTSRC.
As proposed on tech-kern and tech-userlevel on 2022-01-07
and followed up on 2022-08-21.
Split help into synopsis and help.
Only display the synopsis for usage errors (not the full help).
Print usage errors to stderr not stdout.
Don't print a usage error for -? before the help message.
Improve error messages for unknown options and missing arguments.
Remove trailing "." present in some error messages.
Alway use 'quote' instead of `quote' in some error messages.
HOST_CPPFLAGS, HOST_CXXFLAGS, but not LIBRARY_PATH because it breaks
the build. These variables are necessary to support building NetBSD
from a GNU Guix or NixOS host, where /usr/include, /lib, and all
but /bin/sh do not exist. In many cases, support for HOST_CPPFLAGS
was incomplete. From Ryan Sundberg
build with -P would use. Example usage:
./build.sh -T /usr/tools -P mkrepro-timestamp
This allows us to extract this information once, make other use of it,
and replicate it on other machines with -V MKREPRO=yes -V MKREPRO_TIMESTAMP=..
from the uname -p value already fetched.
this means eg, build.sh on evbarm will build the native platform rather
than "earm" (armv5) -- which was the default even on arm64 hosts.
- sys/arch/evbarm64 is gone and integrated into sys/arch/evbarm. (by skrll@)
- add support fdt. evbarm/conf/GENERIC64 fdt (bcm2837,sunxi,tegra) based generic 64bit kernel config. (by skrll@, jmcneill@)
it trivial to add a list of banned var names for either of those args
should that ever be considered desireable (as the XXX suggests it might.)
I've had this mod locked in my tree for (at least) months - time to set it free.
it is not "good" just because ../xsrc or /usr/xsrc exists, if the user said
-X /no/xsrc/here ... Further, when we find it, remember it.
While here, also look in my favourite place: .../src/xsrc - src/x would be
better (or src/x11) but that's too hard given the cvs module name and src
tarball format.