On Mon, 05 Feb 1996 23:18:33 -0800 
 "Michael L. VanLoon -- HeadCandy.com" <michaelv@HeadCandy.com> wrote:

[ Was. Re: mfs, ramdisk, whatever ]

[ Perry's comments... ]
 > >Yet more reasons that a bunch of this configuration information should
 > >be in /etc, per CGD's recent suggestion. I find myself constantly
 > >re-editing the contents of share/mk to customize such things (these
 > >changes get blown away by my "make build"s) and I wonder how well this
 > >would work at all in an NFS environment. You should be able to set
 > >all this stuff in /etc, along with all the other host specific data.


[ Michael's comments... ]
 > I'm not convinced compiler configuration stuff belongs in /etc.  Maybe
 > we could add something to the system makefiles that sucks in a
 > /usr/share/mk/local.mk, or something similar, if it exists, that could
 > override defaults.  If you really think it belongs in /etc, just
 > symlink it (I know... "symlinks are evil", but this is what they're
 > good for...).

I definitely agree with Perry on this one.  For example, I'd like to use 
"-O -pipe" on my 32mb hp380 but only "-O" on my 8mb hp319.  One could 
argue that I shouldn't ever compile anything on the 319, but that's not 
the point :-)  Since these systems share "/usr/share" (in fact, my 
/usr/share is shared between an hp340, hp319, hp380, sun3/60, sun4/260, 
and mvme-147), I can't use /usr/share/mk/local.mk to set those 
machine-specific variables.

However, with Chris's current PR (#1970), the issue of overriding CFLAGS, 
compiler, etc. isn't even addressed.  Those are dealt with in sys.mk and 
Chris's changes only cover bsd.own.mk.  To deal with this, sys.mk and 
bsd.own.mk both need to include /etc/mk.conf, but I don't particularly 
like the idea of defining bsd.own.mk variables (by inclusion) in sys.mk 
and vice-versa.  I've though of a way to address that, but it's so ugly 
that I don't want to mention it in public :-)

Of course, /etc/mk.conf is likely to define 3 or 4 things tops on any 
given system, so perhaps the over-inclusion problem isn't really much of 
a problem and not deserving of any extra brain cycles.

Comments?  I'm going to be doing this in my own private source trees, but 
I'd like to do it well enough for it to go into the master sources.

--------------------------------------------------------------------------
Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                               Home: 408.866.1912
NAS: M/S 258-6                                          Work: 415.604.0935
Moffett Field, CA 94035                                Pager: 415.428.6939