K 10
svn:author
V 3
jah
K 8
svn:date
V 27
2018-07-10T01:06:43.532641Z
K 7
svn:log
V 1703
MFC r328489, r329232, r331836

r328489:

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
environment.

This fixes "Variable OBJTOP is recursive".

r331836:

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.

END