MKPROFILE MKSHARE, which default to `yes' unless an equivalent NOxxx
variable is defined.
* Add MKCATPAGES, which if "no" prevents catpages from being built or installed
Users should use "MKxxx=no" instead of "NOxxx=" in /etc/mk.conf, because
this allows easy override on the make(1) command line (e.g 'make MKSHARE=yes'
to override MKSHARE=no in /etc/mk.conf).
and the filesystem is full. Added ${RENAME} flag to install, which when set
to -r installs on a temporary file and then renames to the final destination.
${RENAME} is currently set to nothing in bsd.own.mk, but one can turn it
on in /etc/mk.conf.
tech-toolchain for a very detailed explanation of this. In short, add
a .y.h rule identical to the .y.c rule and make the .y.c rule rename
the .h file; also, clean the .h file in CLEANFILES.
* Allow bsd.man.mk to be included separately.
* Always include bsd.own.mk and bsd.obj.mk.
* Include bsd.man.mk and bsd.nls.mk even if NOMAN or NONLS; just turn off
building of the affected files instead.
* Require bsd.subdir.mk to be included explicitly.
(Will make appropriate changes to Makefiles shortly.)
and libs in the object tree, if you use a separate object tree,
while maintaining backward compatability with other build methods.
See the notes in src/share/mk/bsd.README for full details. Note
that the `make includes' target now only installs the include files
in the build directory (if you use one--otherwise they go in DESTDIR
just like before); `make install' will install include files in
DESTDIR.
a bunch of rules, define a clean{kmod,lib,prog} target with the rules,
and have both clean and cleandir depend on that. That eliminates a bug
where 'cleandir' in a directory which included e.g. bsd.prog.mk but which
also had subdirs would 'make clean' all the subdirs and then 'make cleandir'
all ofthe subdirs. It also allows Makefiles to add more dependencies
to 'clean' after inclusion of the make template.
If 'clean' is already defined, the behaviour is the same as it used to be.
the .depend file to add <filename>.ln for each <filename>.o as an
object file which has the given dependencies (in addition to
<filename>.po and <filename>.so, which were already there).