svn commit: r284598 - head/share/mk

[Simon J. Gerraty]

Bryan Drewery <bdrewery at FreeBSD.org> wrote:
> >   head/share/mk/local.sys.mk
> 
> I'm bothered by the amount of local.* files committed in the tree. I
> expect, as a user and working in a downstream product, that a local.*
> file is MINE, not FREEBSD. The pattern of using 'local' is quite common
> as a *user* file.

Yes that's exactly the point.
local*mk (and src*) do not get installed in /usr/share/mk, yet the
inlcudes exist as points for you to customize the behavior.

> Why are these named as such? It seems they should just be 'src.' with
> .sinclude hooks for actual local overrides.

local* are name as such since that's all that bsd* should know about.
Providing for local customization.

Ideally the local.*.mk in src/share/mk would do nothing except include 
src.*mk which is where the smarts for building src should be.
But /usr/share/mk/ should know noting about src*
since it is supposed to be generically useful infra.

There's extra stuff there because it might be useful as an example.
We can work on that over time I guess.

After many years consulting and providing tools to customers,
I really like making it possible for them to customize without touching
(hacking) any of the original bits, it has worked very well.

That's key when you get to something really complicated like dirdeps.mk

> > +# site customizations that do not depend on anything!
> > +SRC_ENV_CONF?= /etc/src-env.conf
> > +.if !empty(SRC_ENV_CONF) && !target(_src_env_conf_included_)
> > +.-include "${SRC_ENV_CONF}"
> > +_src_env_conf_included_:	.NOTMAIN
> >  .endif
> 
> This needs to be documented in at least src.conf(5). I'm concerned that
> the need to add this indicates subtle changes elsewhere that may break
> existing /etc/src.conf setups, but I cannot find an example.

Sorry, I didn't do the above originally; what is the concern?

> > +# late include for customization
> > +.-include <local.sys.mk>
> 
> In local.sys.mk from r284345 is an inclusion of SRCCONF, which is now
> different and earlier than before. I wonder if this should move back to
> only being included from bsd.own.mk (there is even a lingering
> WITHOUT_SRCCONF check in that file). The way it is now is very obscure
> in terms of when it is actually included and from where.

Since I didn't move the inlcude of src.conf from bsd.own.mk
(I would *guess* it was part of the src.opts changes) I'm not sure 
what the pros/cons of the two locations are.
Certainly changing *anything* has potential to bite someone,
but it is very hard to improve without change.