conf/144079: Makefile.inc1 ${DESTDIR} make dependency enhancement

[Garrett Cooper]

The following reply was made to PR conf/144079; it has been noted by GNATS.

From: Garrett Cooper <yanegomi at gmail.com>
To: Ruslan Ermilov <ru at freebsd.org>
Cc: bug-followup at freebsd.org
Subject: Re: conf/144079: Makefile.inc1 ${DESTDIR} make dependency enhancement
Date: Fri, 19 Feb 2010 12:47:08 -0800

 Hi Ruslan!
 
 On Fri, Feb 19, 2010 at 4:38 AM, Ruslan Ermilov <ru at freebsd.org> wrote:
 > Garrett,
 >
 > On Thu, Feb 18, 2010 at 11:30:03PM +0000, Garrett Cooper wrote:
 >> =A0 =A0 =A0The patch on the right track,
 >
 > I don't think so. =A0Our install-related targets never create
 > directories themselves; instead, they expect them to be pre-
 > created, e.g. by mtree.
 
 Yes, but mtree doesn't handle creating DESTDIR beforehand AFAIK on
 RELENG_8, which is where I was getting shot at... I did some more
 hunting and after figuring out the proper terminology for the method,
 it turns out that the overall `build process' is discussed under
 http://www.freebsd.org/doc/handbook/jails-build.html -- which is a bit
 different from what I expected because the general topic applies to
 installing out-of-build tree, in general, which is paramount for
 releases and building for embedded devices, etc.
 
 >> =A0but wasn't complete, so I had to be
 >> =A0a bit more invasive with where the DESTDIR dependencies went (filled
 >> =A0in all missing dependencies based on inspection) and where the goal
 >> =A0itself goes (bsd.own.mk).
 >> =A0 =A0 =A0I'm not happy about the placement of the goal, and I'm open t=
 o
 >> =A0move it to another location if one exists, as bsd.own.mk seems to be
 >> =A0purely variable driven data setting without goals.
 >
 > Why all this churn, what are you trying to achieve? =A0Save
 > one mkdir command? =A0Why the proposed ${DESTDIR} dependency
 > only covers etc/, include/, and sys/modules/ makefiles?
 
 The intent was to cover the implied ${DESTDIR} dependency for the sake
 of completeness, because determining that an issue is present (and
 recovering automatically if possible) via make is much quicker than
 discovering after an install command failed that you have an issue
 with your environment setup because some assumptions that are made
 about it haven't been fulfilled (in this case ${DESTDIR} doesn't
 exist).
 
 There are a few niceties thrown about the tree, and if you execute a
 set of goals in any particular order, depending on what -j you specify
 you'll run into non-deterministic cases because base directories (in
 some targets) are being created via mkdir -p, whilst others aren't
 (build32 and an etc distribute-dirs is an excellent example of what
 I'm trying to illustrate, if it executes the latter step before the
 former one and gets to the install before mkdir -p is executed).
 
 Thanks!
 -Garrett