o Makefile: 1.319, 1,320
o Makefile.inc1: 1.500, 1.508, 1.509, 1.513, 1.515, 1.517
- Embed the "buildkernels" target into the "universe" target so that
the "make -n universe" output looks more builder (human) friendly.
- Wrap the "universe" target into a ".if make(universe)"; it's only
intended to be called directly so it should be safe to do it.
- Make the `distrib-dirs' target official and working properly
when cross-building (installing). (This is useful for NFS
installing world/kernel to another architecture machine.)
- Remove duplicate settings from LIB32MAKE definition.
- Install lib32 bits using the real install(1) program.
- clean ${LIB32TMP} in _worldtmp
- clean ${OBJTREE}/lib32 in _cleanobj
- ensure that ${WORLDTMP} exists in build32
- Require DESTDIR to be set when cross-installing.
- Force a full Groff upgrade during the build.
native and foreign architectures and comparing products).
They eliminate most of the differences caused by different
object directory paths, timestamping, and identification.
(Note WORLDTMP was renamed to ${OBJTREE}${.CURDIR}/tmp.)
introducing the disk formats for _RuneLocale and friends.
The disk formats do not have (useless) pointers and have 32-bit
quantities instead of rune_t and long. (htonl(3) only works
with 32-bit quantities, so there's no loss).
Bootstrap mklocale(1) when necessary. (Bootstrapping from 4.x
would be trivial (verified), but we no longer provide pre-5.3
source upgrades and this is the first commit to actually break
it.)
intent was (and still is) that if a user has say
CPUTYPE=i686 set in /etc/make.conf, we don't print
the assignment type warning unless TARGET_CPUTYPE
is overridden.
Unfortunately, the implementation was buggy, and
only recent changes to bsd.cpu.mk that swapped
canonical and alias values of some CPU types made
the bug apparent.
Here's what happens here.
- CPUTYPE=i686 is set in /etc/make.conf,
- bsd.cpu.mk reset it to "pentiumpro",
- Makefile.inc1 compares this canonical value
with the result of the following test,
make -f /dev/null CPUTYPE=pentiumpro -V CPUTYPE
and expects the result to be "pentiumpro" too,
but "i686" is returned, here's why. We have two
CPUTYPE variables, global, set to "i686" in
/etc/make.conf, and command-line (of a higher
precedence), set to "pentiumpro".
The following part of bsd.cpu.mk,
. elif ${CPUTYPE} == "i686"
CPUTYPE = pentiumpro
which is responsible for converting aliases to
canonical values, sees the value of the CPUTYPE
command-line variable first, "pentiumpro", and
no conversion is done -- the net effect is that
CPUTYPE global stays with its old value "i686",
and "make -V CPUTYPE" (which prints variables
in the global context) returns "i686".
The fix was to pass the CPUTYPE in the test above
as an environment variable instead of as a command
line variable, i.e.,
CPUTYPE=pentiumpro make -f /dev/null -V CPUTYPE
This time, CPUTYPE global is still set to "i686"
initially (by /etc/make.conf), and an envieronment
variable CPUTYPE (of a lower precedence) is set
to "pentiumpro". The .elif sees it's set to
"i686" and resets it to "pentiumpro", and so
"make -V" returns "pentiumpro".
NB: these various types of make(1) variables can
be very painful, especially when combined with
"make -V".
building the kerberos5 includes. This is not the same patch that
Bjoern A. Zeeb came up with, but the credit still goes to him for finding
the problem. Thanks!
If turned on no NIS support and related programs will be built.
Lost parts rediscovered by: Danny Braniss <danny at cs.huji.ac.il>
PR: bin/68303
No objections: des, gshapiro, nectar
Reviewed by: ru
Approved by: rwatson (mentor)
MFC after: 2 weeks
