- Add a note about the organisation of the sections.
- Expand shell globs (they worked in a previous version of the delete-old
target, but not in this one).
- Use the correct way of checking for a native environment. [1]
- Add some more obsolete files.
- Fix some bad english. [1]
Suggested by: ru [1]
Approved by: mentor (joerg)
- removes obsolete files/dirs or libraries.
- works in interactive (default) and batch mode
- respects DISTDIR
- documented in UPDATING and build(7)
The head of the file ObsoleteFiles.inc contains instructions how to add
obsolete files/dirs/libs to the list. Obviously one should add obsolete
files to this list, when he removes a file/dir/lib from the basesystem.
Additionally add check-old target:
- allows re@ to check if a file on the obsolete list resurfaces
Design goals:
- allows full control by the user (default interactive mode)
- possibility of scripted removal of obsolete files (batch mode)
- opt-in removal of files (explicit list of files)
- seperate removal of libs (2 delete targets)
Important design decissions:
- structured list of files to remove instead of a plain text file:
* allows to remove additional files if a NO_foo knob is specified
without the need to change the targets (no NO_foo knob is respected
yet)
- not using mtree like NetBSD does:
* mtree doesn't has an interactive mode
Discussed on: arch (long ago), current (this year)
Additional input from: re (hrs)
Approved by: mentor (joerg)
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
