* Don't make OBJECT_FMT dependent on USE_NEW_TOOLCHAIN. All ports
except ns32k are ELF, so set it appropriately. Allow it to be
overridden in the ns32k case.
* If ns32k && USE_NEW_TOOLCHAIN, don't build shared libraries, because
external toolchains don't support them for our a.out.
* If ns32k && OBJECT_FMT == ELF, the GNU platform is "netbsdelf".
* If ns32k && USE_NEW_TOOLCHAIN, don't attempt to build the in-tree
binutils 2.11.2, gdb 5.0, or gcc 2.95.3.
This allows us to do USE_NEW_TOOLCHAIN cross-builds to ns32k using
an external toolchain.
There were too many synchronisation problems with using the former;
including situations such as a "make clean" performed between two
installs to the same DESTDIR would result in a truncated METALOG and
the resultant sets would be missing stuff such as include files that
don't get reinstalled if they haven't changed, even with !UPDATE.
Sources for a target do not accumulate over dependency lines
when this operator is used.
An unstated implication of this is that when parallel builds are done,
each separate instance of the target can be scheduled independantly.
As a result, the linksinstall target with commands could be executed
too early during a parallel build since they didn't actually have a
dependancy on "realinstall".
To fix this, correct the linksinstall:: realinstall dependancy by
eliminating the command-less linksinstall target, and moving the
dependancy to the other linksinstall target.
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.
determined, since BSDSRCDIR's default of /usr/src might not exist and the
calculation of _SRC_TOP_OBJ_ would then generate a warning :-(.
_SRC_TOP_ can now == "" if make(1) (or a parent make(1)) was started
outside of the NetBSD source tree.
Now, if _SRC_TOP_ != "", BSDSRCDIR defaults to ${_SRC_TOP_} and
BSDOBJDIR defaults to the objdir of ${BSDSRCDIR}.
Failsafe defaults for BSDSRCDIR (/usr/src) and BSDOBJDIR (/usr/obj)
are provided later in the file.
This should result in a usable BSDSRCDIR default (i.e, _SRC_TOP_ if
running from within the source tree), with safe fallbacks as appropriate
(/usr/src, as always), meaning that BSDSRCDIR should be able to be used
instead of _SRC_TOP_ in the source tree, although I need to carefully
test this. *aaaiiiieeee!!!*. (Now I understand some of Todd's pain :)
make -V FILES
from being useful (and given that every other variable can be
extracted using make -V, the behaviour was unusually inconsistent
given that the original reason for clearing it doesn't seem to be
relevant anymore)
- use <bsd.prog.mk> instead of directly including <bsd.files.mk>
(and possibly <bsd.man.mk> or <bsd.own.mk>)
- remove obsolete NOPROG
${BSDSRCDIR} if make(1) is running outside of the NetBSD source tree.
This should solve various issues, including building xsrc which uses
${BSDSRCDIR}/distrib/sets/maketars.
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.
Instead of:
install -m 600 [...]
ranlib -t [...]
chmod 444 [...]
use the newly added "-a" flag to install(1) to invoke ranlib ifndef UPDATE.
Should prevent unnecessary ranlib-ing of installed libraries with UPDATE
defined.
Per discussion with simonb.
thorpej