One build system, three targets, three tiers

1buildkernel NO_MODULES — tier 1, stays stock

Stock make buildkernel's all target is kernel-all + modules-all (in sys/conf/kern.post.mk). Passing NO_MODULES=yes (a flag — not a Makefile edit) drops the modules half, leaving just the kernel image. installkernel NO_MODULES=yes installs only the kernel to /boot/kernel.

make buildkernel   KERNCONF=NEXTBSD NO_MODULES=yes
make installkernel KERNCONF=NEXTBSD NO_MODULES=yes DESTDIR=${STAGE}

Crucially this leaves behind the configured kernel obj tree — the config stage's opt_*.h, the machine/ symlinks, and the kernel-toolchain — which the next target needs. Because it's just a flag on a stock target, buildkernel stays byte-for-byte upstream (keeps the monorepo's merge-clean rule intact).

2buildextensions — in-tree klds + kexts (tiers 2–3)

A NextBSD-owned target that builds sys/modules the way buildkernel used to, then wraps the kext-tier drivers. It emits a mix: the ~250 plain klds stay plain .ko, and the ~30 firmware drivers get wrapped into .kext bundles via a shared bsd.kext.mk.

# nextbsd/extensions/Makefile — invoked AFTER buildkernel (needs its obj tree)
KODIR?= ${OBJTOP}/${MACHINE}.${MACHINE_ARCH}/${SRCTOP}/${KERNCONF}/modules${SRCTOP}/sys/modules
.include "${SRCTOP}/nextbsd/share/mk/nextbsd.kexts.conf"   # the KEXTS table = the naming manifest

buildextensions: .PHONY
	cd ${SRCTOP}/sys/modules && ${MKMODULESENV} ${MAKE} all   # build every .ko (tier 2)
.for k in ${KEXTS}                                            # wrap only the firmware/multi-version ones (tier 3)
	@${MAKE} -f ${SRCTOP}/nextbsd/share/mk/bsd.kext.mk extension \
	    KEXT_NAME=${${k}_NAME} KEXT_ID=${${k}_ID} KO=${KODIR}/${${k}_KO} \
	    KEXT_PERSGEN=${SRCTOP}/nextbsd/tools/gen-${${k}_GEN}-personalities.sh \
	    KEXT_FW="${${k}_FW}" KEXT_DEPS="${${k}_DEPS}"
.endfor

bsd.kext.mk is the formalized ko2kext.sh: it takes an already-built .ko, runs the personality generator, bundles firmware into Resources/, writes Info.plist + OSBundleLibraries, and stages <Name>.kext/Contents/MacOS/<ko>. Move ko2kext.sh + gen-*-personalities.sh from the separate nextbsd-kernel-modules repo into nextbsd/tools/.

3buildgraphics — out-of-tree GPU/nvidia (tier 3)

drm-kmod (i915kms/amdgpu/radeonkms + the drm/ttm/dmabuf cores) and nvidia are ports, not sys/modules, so buildextensions can't reach them. They already need bespoke recipes (fetch, patch, per-branch), which is exactly why they get their own target — and their custom names cost nothing extra.

• drm-kmod: vendor into nextbsd/vendor/drm-kmod/ (self-contained, but a second upstream-sync burden) or fetch at build.
• nvidia: must fetch the tarball at build (non-redistributable blob), patch it, build each branch (595/580/470/390/340/304), wrap into NVIDIAGraphics<NNN>.kext.
• Both feed the same bsd.kext.mk wrap and install to the same /System/Library/Extensions.

4buildworld — unchanged

Userland only; it never touched kernel modules. Completely stock, runs in any order relative to the kernel/extensions targets. Your custom userland tools ride in via the LOCAL_DIRS/LOCAL_LIB_DIRS hooks (see the monorepo plan §5), not here.

5The one open decision: Pure vs Mixed install layout

The build split above is compatible with both. What differs is where the loadable drivers install and who matches them — and it hinges on whether /boot/kernel holds loose klds.

6Alternatives — fewer targets for local building

Four ordered targets with flags is great for CI (selective builds need the granularity) but heavy for a developer who just wants "build me a working system." The fix isn't fewer capabilities — it's a friendlier front door. Three options, not mutually exclusive.

Recommendation: granular targets for CI + a make nextbsd umbrella and build.sh for local (A); and if you adopt Mixed, Option C makes routine local builds just stock FreeBSD. For iterating on a single driver you don't need any of this — cd sys/modules/foo && make already works after one full build.

7Ordering, incremental, and selective CI

• Ordering: buildextensions/buildgraphics depend on buildkernel's configured obj tree (opt headers, toolchain) — enforce buildkernel → {extensions, graphics}. buildworld is independent.
• Incremental: tier-2 klds get meta-mode incremental for free (unchanged .ko isn't relinked). Key each .kext off its .ko mtime (+ the personality generator + firmware set) so a bundle re-wraps only when its inputs move; wrapping is cheap, so rebuild-on-.ko-change is safe.
• Selective CI: gate the kernel+extensions job on sys/** + nextbsd/{extensions,tools,share/mk}/**; gate buildgraphics on the vendored/pinned drm-kmod + nvidia refs. A sys/-only change rebuilds kernel + affected klds/kexts, not GPU; a drm-kmod bump rebuilds only graphics.

8Keep upstream clean — exact touch list

Everything that enters the tree is a NextBSD-owned new file; no stock build file is edited.

Stock Makefile.inc1, kern.post.mk, kmod.mk, bsd.kmod.mk, sys/modules/Makefile, and GENERIC stay untouched — so upstream merges never conflict on the build system.

9Open decisions

• Pure vs Mixed (§5) — the load-bearing call. Everything downstream (personality count, matcher scope, /boot/kernel contents) follows from it.
• drm-kmod: vendor vs fetch — self-contained tree (second sync burden) vs simpler tree (build-time fetch).
• Firmware discovery (D4) — serve from Resources/ (needs a firmware(9) hook, avoids /boot/firmware) vs nest a firmware .ko (unchanged firmware_get()) vs raw /boot/firmware files (FreeBSD-15 path).
• Multi-.ko kext packaging — ko2kext.sh can't yet bundle nvidia's nvidia+modeset+drm under one CFBundleExecutable; needed before buildgraphics ships nvidia KMS.