- sys.mk:
add ${OBJC} and ${OBJCFLAGS} (equivalent to ${CC} and
${CFLAGS} respectively), and ${COMPILE.m} and ${LINK.m} rules
- bsd.sys.mk:
add .m, .m.o, and .m.ln rules (as per the C rules in sys.mk).
it's here, rather than in sys.mk, because `.m' isn't
exclusively used for Objective C files.
- bsd.lib.mk:
add .m.o, .m.po, .m.so, and .m.ln rules (as per C)
* 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.
support the two different incompatible rules for build .so files from
.S source on both NetBSD and binutils toolchains:
${CPP} | ${AS} for syscalls
${CC} for non-syscalls
for which the different toolchains's ${AS} requires diffferent flags.
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.
libraries with LD, but add /usr/lib/crtbegin.o and /usr/lib/crtend.o
before and after the rest of the stuff being linked. This is a losing
situation all-around: for correct 'DESTDIR' builds, it should be including
them from ${DESTDIR}/usr/lib. However, since those objects should be
included for all shared libraries, including them from ${DESTDIR} won't work,
because they won't be installed by normal builds by the time they need to
be used.