Jason said:
> 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.

Note also that the mechanism by which i added /etc/mk.conf in the PR
allows for something much more general than '/usr/share/mk/local.mk'.

In particular, if i have 5 users on a machine, each of which has their
own copy of /usr/src, and each of which has their own copy of
/usr/obj, and i want 'make obj' to DTRT with symlinks, etc.,
you just _can't_ do that witk /usr/share/mk/local.mk.
You _can_ do that with the proposal i sent in in the PR.

> 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 :-)

My concern was for -- and only for -- building NetBSD source trees.

/etc/mk.conf as i proposed it was meant to be a way to configure the
NetBSD build process and that was _it_.


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

/etc/mk.conf should be able to define _anything it wants_, without
being limited by the set of things which are supposed to go in sys.mk.

For instance, is it a good idea for sys.mk to define the make variable
"KERBEROS"?  How about the more common "BSDSRCDIR"?

I can think of a few reasons why i might want bsd.own.mk to define
those, and a lot more things...  And if those definitions are
automatically included in program makefiles, what will happen?
(hint: "nothing good."  8-)


I guess my thing is, i build NetBSD sources every day.  I build
'other' sources rather infrequently, and usually when i do i'm either
not concerned with the flags to various tools used in the build, or
the programs' build processes divine the right tools automatically.



cgd