Subject: Re: Kernel include files
To: None <current-users@NetBSD.ORG>
From: Charles M. Hannum <mycroft@gnu.ai.mit.edu>
List: current-users
Date: 01/05/1995 13:28:02
I keep thinking of DESTDIR as a non-used no-op on most
software systems ...
Yah, well, there are two reasons we have to think about it:
1) cross-compilation, and
2) bootstrapping from another, not-so-friendly, environment.
`Most software systems' don't have either of those problems. B-)
What if I were to propose the idea of having "make" look at an envariable
(e.g., "MAKESYSPATH", or maybe overload the old "VPATH"?) that, if set, would
tell "make" where to look instead of "/usr/share/mk" and (for syspath)
"/usr/share/mk/sys.mk"? (i.e., overrule _PATH_DEFSYS{MK,PATH})
Someone already mentioned the `-I' option to make(1) and the `-M'
option to troff. (I didn't really look for these at the time because
I didn't need them.) The latter is obviously trivial to put in
bsd.man.mk; it's not quite clear how to incorporate the former except
for subdirectories, and that's not really sufficient.
I suppose we could prefix all the paths in the .include's with
$DESTDIR, but that's kind of ugly, and it still assumes that sys.mk is
compatible.
We could, of course, tell the user to:
alias make make -I${DESTDIR}/usr/share/mk
for cross-compilation, or do as you say and have make(1) look at yet
another magic variable. (I'm kind of hesitant to use DESTDIR inside
make(1) itself...)
It's not clear to me what the right thing to do is.