SYMLINKS to install symlinked header files. INCSYMLINKS are installed with
'make includes'. This avoids using SYMLINKS and hacks with the 'linkinstall'
target in <bsd.links.mk>, as linksinstall occurs in 'make install' and hacks
to get it to occur in 'make includes' weren't robust, as seen in lib/libdes.
Yet more improvements to bsd.README.
* DPSRCS contains extra dependencies, but is _NOT_ added to CLEANFILES.
This is a change of behaviour. If a Makefile wants the clean semantics
it must specifically append to CLEANFILES.
Resolves PR toolchain/5204.
* To recap: .d (depend) files are generated for all files in SRCS and DPSRCS
that have a suffix of: .c .m .s .S .C .cc .cpp .cxx
* If YHEADER is set, automatically add the .y->.h to DPSRCS & CLEANFILES
* Ensure that ${OBJS} ${POBJS} ${LOBJS} ${SOBJS} *.d depend upon ${DPSRCS}
* Deprecate the (short lived) DEPENDSRCS
Update the various Makefiles to these new semantics; generally either
adding to CLEANFILES (because DPSRCS doesn't do that anymore), or replacing
specific .o dependencies with DPSRCS entries.
Tested with "make -j 8 distribution" and "make distribution".
Update documentation for some other make variables
some build problems where DPSRCS contains .h files that need to exist to
build the .d file.
document that bsd.dep.mk should be included after anything that might
update SRCS or DPSRCS so that the above works correctly, and actually
ensure this is the case.
Clarify that command-line overrides of the MKxxx variables should be
done via the environment rather than make(1) command-line variable
assignment, since the latter doesn't actually work as intended.
COPTS.<fn> Additional flags to the compiler when creating the C objects
for <fn>.
CPUFLAGS.<fn> Additional flags to the compiler/assembler for <fn>.
CPPFLAGS.<fn> Additional flags to the C pre-processor for <fn>.
(For <fn>.[ly], "<fn>.c" must be used.)
Replace defined(UNPRIVED) tests with ${MKUNPRIVED} != "no"
Add MKUPDATE; if not no has the same semantics as if UPDATE was defined.
Replace defined(UPDATE) tests with ${MKUPDATE} != "no"
Improve documentation for these and other make flags.
This replaces the previous .if defined (MANZ) behaviour, although the latter
will set MKMANZ=yes for compatibility purposes.
Don't bother with -P-bou in TOOL_ROFF_HTML; it doesn't appear to be
necessary with groff 1.19.
Fix NOHTML implementation to be consistent with other NOxxx / MKxxx
variables, and expose the user-tweakable MKHTML.
program/tool from "FOO" to "TOOL_FOO". The new variables are:
TOOL_ASN1_COMPILE TOOL_CAP_MKDB TOOL_CAT TOOL_CKSUM TOOL_COMPILE_ET
TOOL_CONFIG TOOL_CRUNCHGEN TOOL_CTAGS TOOL_DB TOOL_EQN TOOL_FGEN
TOOL_GENCAT TOOL_GROFF TOOL_HEXDUMP TOOL_INDXBIB TOOL_INSTALLBOOT
TOOL_INSTALL_INFO TOOL_M4 TOOL_MAKEFS TOOL_MAKEINFO TOOL_MAKEWHATIS
TOOL_MDSETIMAGE TOOL_MENUC TOOL_MKCSMAPPER TOOL_MKESDB
TOOL_MKLOCALE TOOL_MKMAGIC TOOL_MKTEMP TOOL_MSGC TOOL_MTREE
TOOL_PAX TOOL_PIC TOOL_PREPMKBOOTIMAGE TOOL_PWD_MKDB TOOL_REFER
TOOL_ROFF_ASCII TOOL_ROFF_DVI TOOL_ROFF_HTML TOOL_ROFF_PS
TOOL_ROFF_RAW TOOL_RPCGEN TOOL_SOELIM TOOL_SUNLABEL TOOL_TBL
TOOL_UUDECODE TOOL_VGRIND TOOL_ZIC
For each, provide default in <bsd.sys.mk> of the form:
TOOL_FOO?= foo
and for the ${USETOOLS}=="yes" case in <bsd.own.mk>, provide override:
TOOL_FOO= ${TOOLDIR}/bin/${_TOOL_PREFIX}foo
Document all of these in bsd.README.
This cleans up a chunk of potential (and actual) namespace collision
within our build infrastructure, as well as improves consistency in
the share/mk documentation and provision of appropriate defaults for
each of these variables.
the environment:
CPUFLAGS Additional flags to the compiler/assembler to select
CPU instruction set options, CPU tuning options, etc.
Since CPUFLAGS is not implicitly set by any part of the make infrastructure,
it is safe to set in mk.conf, unlike COPTS or DBG.
-dynamic-linker=/libexec/ld.elf_so) if the BINDIR of the program being
built is /bin or /sbin.
The reason we do this is because now all programs *except* those in
/bin and /sbin (i.e. the "special cases") match the default the compiler
uses, which is what is used for things in e.g. xsrc, pkgsrc, and other
random 3rd party programs.
This is done by decoupling where a shlib is installed from how it
is located. Two new variables, SHLIBINSTALLDIR and SHLINKINSTALLDIR,
contain the former information, and key off MKDYNAMICROOT only. SHLIBDIR
and SHLINKDIR contain the latter, and key off MKDYNAMICROOT and BINDIR.
The SHLIBINSTALLDIR, SHLIBDIR, _LIBSODIR, SHLINKINSTALLDIR, and
SHLINKDIR parameters are moved to a new <bsd.shlib.mk>; see bsd.README
for usage details.
This means that:
+ /bin and /sbin (and the few programs in /usr/* which were statically
linked) are now dynamically linked.
+ The shared libraries that are needed by the /bin and /sbin programs
are now installed into /lib (with compatability symlinks from
/usr/lib). These are:
c crypt edit ipsec kvm m m387 termcap termlib util z
+ The shared linker is now in /libexec/ld.elf_so, and
/usr/libexec/ld.elf_so is a symlink to the former.
If you want the prior behaviour of "some applications statically linked,
the rest dynamically linked", set MKDYNAMICROOT=no in your mk.conf(5).
If you have a philosophical objection to dynamic libraries, continue
to set LDSTATIC=-static in your mk.conf(5), and please don't waste any
more time in trying to convince us why dynamic libraries are 3v1l.
two variables:
TOOLCHAIN_MISSING -- set to "yes" on platforms for which there is
no working in-tree toolchain (hppa, ns32k, sh5, x86_64).
EXTERNAL_TOOLCHAIN -- if defined by the user, points to the root of
an external toolchain (e.g. /usr/local/gnu). This enables the cross-build
framework even for TOOLCHAIN_MISSING platforms.
If TOOLCHAIN_MISSING is set to "yes", MKGDB, MKBFD, and MKGCC are all
unconditionally set to "no", since the bits are not there to build.
If EXTERNAL_TOOLCHAIN is set, MKGCC is unconditionally set to "no",
since the external toolchain's compiler is not in-sync with the
in-tree compiler support components (e.g. libgcc).
* Set MACHINE_CPU much earlier in bsd.own.mk, so that more tests in
that file can use it.
Defaults to the directory determined by the _SRC_TOP_ logic (if != ""),
and the BSDSRCDIR.
NETBSDSRCDIR has been provided for use by the various NetBSD source
Makefiles to find the top of the NetBSD source tree, and isn't
affected by the inheritance properties of _SRC_TOP_, nor does it
have the magic BSDOBJDIR baggage that BSDSRCDIR is stuck with.
infrastructure and using that infrastructure in programs.
* MKHESIOD, MKKERBEROS, MKSKEY, and MKYP control building
of the infratsructure (libraries, support programs, etc.)
* USE_HESIOD, USE_KERBEROS, USE_SKEY, and USE_YP control
building of support for using the corresponding API
in various libraries/programs that can use it.
As discussed on tech-toolchain.
lukem