to make it call `install' in the bsd.subdir.mk-driven makefiles
too. (share/examples/Makefile,v 1.29 changed the bsd.prog.mk
to bsd.subdir.mk and many stuff was lost during "make release".
I then merged this change in rev. 1.28.2.2 to work around the
namespace pollution (FILES) in this makefile.)
There was an added complexity here. Both the `distribute' and
`install' targets are recursive (they propagate to SUBDIRs).
So `distribute' first calls `install' in the ${.CURDIR}, then
calls `distribute' in each SUBDIR, etc. The problem is that
`install' (being also recursive) causes the stuff from SUBDIR
to be installed twice, first time thru `install' in ${.CURDIR}
triggered by `distribute', second time by `distribute' run in
the SUBDIR. This problem is not new, but it became apparent
only after I moved the `distribute' target from bsd.obj.mk to
bsd.subdir.mk. My first attempt testing the fix failed due to
this, because the whole world was distributed twice, causing
all the imaginable mess (kerberos5 stuff was installed into both
"base" and "krb5" dists, there was /sbin/init.bak, etc.)
I say the problem is not new because bsd.prog.mk and bsd.lib.mk
makefiles with SUBDIR (even without this fix) had this problem
for years. Try e.g. running ``make distribute DISTDIR=/foo''
from usr.bin/bzip2 or from lib/libcom_err (without the fix) and
watch the output.
So the solution was to make `install' behave non-recursive when
executed by `distribute'. My first attempt in passing SUBDIR=
to the `install' in the `distribute' body failed because of the
way how src/Makefile and src/Makefile.inc1 communicate with each
other. SUBDIR='s assignment precedence on the "make install
SUBDIR=" command line is lowered after src/Makefile wrapper calls
"make ... -f ${.CURDIR}/Makefile.inc1 install" because SUBDIR=
is moved into environment, and Makefile.inc1's assignments now
take higher precedence. This may be fixed someday when we merge
Makefile with Makefile.inc1. For now, this is implemented as a
NO_SUBDIR knob.
Spotted by: Dmitry Pryanishnikov <dmitry@atlantis.dp.ua>
Prodded by: des
MFC after: 3 days
8f463ff4c5