MFC r328489, r329232, r331836
Remove system makefile path directives from env passed to PORTS_MODULES step
Previously, MAKESYSPATH as well as '-m' directives in MAKEFLAGS would cause
any port rebuilt during the PORTS_MODULES stage to consume system makefiles
from $(SRCROOT)/share/mk instead of those installed under /usr/share/mk.
For kernel modules that need to build against an updated src tree this
makes sense; less so for <bsd.port.mk> or any userspace library or utility
the port may also happen to install.
Before 11.0, this probably didn't matter much in practice. But the addition
of src.libnames.mk under $(SRCROOT)/share/mk in 11.0 breaks any consumer of
bsd.prog.mk and DPADD/LDADD during PORTS_MODULES.
Address the build breakage by removing MAKESYSPATH and any occurrence of
'-m' from MAKEFLAGS in the environment created for the port build.
Instead set SYSDIR so that any kmod built by the port will still consume
conf/kmod.mk from the updated src tree, assuming it uses <bsd.kmod.mk>
r329232 (by bdrewery):
ports modules: Don't leak AUTO_OBJ changes into the port builds.
This came about when r328489 made ports modules builds no longer use the
in-tree share/mk files, but didn't cleanup MAKEOBJDIR from the
This fixes "Variable OBJTOP is recursive".
Remove MK_AUTO_OBJ from env passed to PORTS_MODULES
This fixes a failure to resolve object file paths seen when buildkernel
(which sets MK_AUTO_OBJ=yes) and installkernel (which sets MK_AUTO_OBJ=no)
are run as separate steps. r329232 partially fixed this scenario by removing
MAKEOBJDIR, but it seems the AUTO_OBJ setting also needs to be on the same
page for the build and install steps.