Change Details

When run at the top level we get whatever mk files the bmake used has with it (unless explicitly overridden with -m). SUB_MAKE is set to include -m pointing at the in-tree share/mk, but the top level does not get that, and so needs to work with the subset that is supported by bmake's own mk files. The tinderbox, toolchains, kernel-toolchains, kernels and worlds targets all recurse into universe and thus work fine in this setting, but targets, universe itself requested at the top level and universe-toolchain (whether explicit or implicitly from a top-level universe) do not. Notably, targets currently gives an empty list due to not having sys.machine.mk's definitions, and universe(-toolchain) have issues recursing into Makefile.inc1 around MAKEOBJDIR(PREFIX). These can all be addressed by introducing new underscore-prefixed targets we recurse into, giving consistency across all universe-related targets.

The top-level Makefile passes -m to its sub-makes in order to ensure they use the in-tree mk files in share/mk, but the top-level make itself has to rely on whatever environment the bmake used has. For FreeBSD, we configure the system bmake with .../share/mk:/usr/share/mk, which means it will pick up src's share/mk whenever run from within the src tree, but currently for non-FreeBSD we configure our bootstrap bmake only with bmake's own mk files. This is mostly compatible, with two exceptions: 1. "targets" runs at the top level, but needs TARGET_MACHINE_LIST and the corresponding MACHINE_ARCH_LIST_${target}, otherwise it will just print an empty list. 2. "universe" and "universe-toolchain", when run at the top level (i.e. not via the various wrappers around universe like tinderbox), end up failing in universe-toolchain itself with: bmake[1]: "/path/to/freebsd/share/mk/src.sys.obj.mk" line 112: Cannot use MAKEOBJDIR= Unset MAKEOBJDIR to get default: MAKEOBJDIR='${.CURDIR:S,^${SRCTOP},${OBJTOP},}' By including .../share/mk in the default sys path like FreeBSD's system bmake we ensure that we get the in-tree mk files for the top-level make, not just sub-makes, and avoid such issues. Note that we cannot (yet) stop using the installed mk files, since the MAKEOBJDIRPREFIX check in Makefile runs in the object directory and uses env -i, thereby losing the MAKESYSPATH exported by src.sys.env.mk. Other such issues may also exist, though are likely rare if so.

When run at tThe top -level we get whatever mk files the bMakefile passes -m to its sub-make used hass in order to ensure with it (unless explicitly overridden with -m).they use the in-tree mk files in share/mk, SUB_MAKE is set tobut the top-level make itself include -m pointing ahas to rely on whatever environment the in-tree share/mkbmake used has. For FreeBSD, but the top level does notwe get thatconfigure the system bmake with .../share/mk:/usr/share/mk, and so needs to work with the subset that is supported bywhich means bmake's own mk files. The tinderbox, toolchains, kernel-toolchainsit will pick up src's share/mk whenever run from within the src tree, kernels and worlds targets all recurse into universe and thus work finebut currently for non-FreeBSD we configure our bootstrap bmake only with in this setting,bmake's own mk files. This is mostly compatible, with two exceptions: 1. but targets"targets" runs at the top level, universe itself requested at the top levelbut needs TARGET_MACHINE_LIST and and universe-toolchain (whether explicit or implicitly from a top-level the corresponding MACHINE_ARCH_LIST_${target}, otherwise it will just universe) do not print an empty list. 2. Notably"universe" and "universe-toolchain", targets currently gives an empty list due towhen run at the top level (i.e. not having sys.machine.mk's definitions not via the various wrappers around universe like tinderbox), aend universe(-toolchain) havep issues recurs failing into Makefile.inc1 around MAKEOBJDIR(PREFIX). universe-toolchain itself with: These can all be addressed by introducing new underscore-prefixed bmake[1]: "/path/to/freebsd/share/mk/src.sys.obj.mk" line 112: Cannot use MAKEOBJDIR= targets we recurse into, giving consistency across all universe-related Unset MAKEOBJDIR to get default: MAKEOBJDIR='${.CURDIR:S,^${SRCTOP},${OBJTOP},}' By including .../share/mk in the default sys path like FreeBSD's system targetsbmake we ensure that we get the in-tree mk files for the top-level make, not just sub-makes, and avoid such issues. Note that we cannot (yet) stop using the installed mk files, since the MAKEOBJDIRPREFIX check in Makefile runs in the object directory and uses env -i, thereby losing the MAKESYSPATH exported by src.sys.env.mk. Other such issues may also exist, though are likely rare if so.