make WITH[OUT]_* more useful?

[Simon J. Gerraty]

On Thu, 17 Apr 2014 10:30:58 -0600, Warner Losh writes:
>This was step one: separate out the options processing from the =
>bsd.own.mk stuff.
>Having a few lines that are generic would be nice to include. I=92d like =
>to go ahead and
>commit step 1, even if we refine things a bit later to keep the change =
>sets manageable
>and under control=85 Is that reasonable? It will help other areas and we =
>don=92t need to
>do much more than settle on filenames. :)

Sure.  Naming stuff is hard, and warrants early attention.
On that front it occurred to me that (since it sets MK_*)
bsd.mkopts.mk might be a good name for the pure mechanism makefile.
So in the 3 level setup I mentioned you'd have:
bsd.own.mk -> bsd.srcopts.mk -> bsd.mkopts.mk

If that sounds ok, I think we can proceed to next step.

>> Sorry, which file are you talking about?=20
>
>My bsd.srcopts.mk was what I was talking about here needing to be added =
>to share/mk/Makefile.

Ah right.  This is why I think separating the mechanism is good.
The mechanism should definitely be installed - because it is very handy
(assuming some of the restrictions are removed).

The /usr/src "policy" is another matter (possibly bikeshed material ;-)

>> FWIW I think all bsd.*.mk should get installed.
>> but I think it perfectly reasonable to declare that anything matching =
>the
>> pattern local.* or src.* doesn't get installed.
>> Hopefully that shouldn't surprise anyone either.
>
>IF we can achieve that separation, then great.

Yep.

>> To restate that slightly differently, you can think of these things as =
>a
>> hierarchy:
>>=20
>> bsd.*	mechanism for building stuff (not just /usr/src)
>> src.*	stuff just for building /usr/src
>> local.*	local tweaks to all the above
>
>Yes, as long as the MK_FOO variables that are really src building stuff =
>don=92t
>infect the bsd.foo.mk files, this could work out. 

Exactly.  

MK_* which are meaningful to bsd.*.mk need an option list in
bsd.*.mk - bsd.own.mk being perhaps a natural location?

For MK_* which are only actioned in makefiles like *bin/Makefile
they can be configured via a src.* file since they do not need to be
installed.

By providing guidance and "obvious" places to list the two classes of
knobs we can limit the infection risk.

>Would we do a wholesale change of bsd.foo.mk to src.foo.mk for all the =
>Makefiles

I'm not sure that would be necessary.
Having to support lots of active branches makes me leery of gratuitous
changes ;-)

If we had sys.mk do

.-include "src.sys.mk"
.-include "local.sys.mk"

that would be sufficient to enable all sorts of cool stuff.
Similarly, bsd.init.mk doing

.-include "src.init.mk"
.-include "local.init.mk"

would allow for customization of things to be done after Makefile has
been read.  

The above would be sufficient to allow src.* to influence bin/Makefile
and lib/Makefile etc without the need to touch them.

Other customization hooks would be cool too, bsd.sys.mk is a somewhat
unfortunate name, but it would be handy to have another point for
including {src,local}.*.mk at the end of the normal lib,prog,* mk files.

Note that even though we don't install src.*.mk or local.*.mk, those
hook points are still very useful to anyone building their own stuff
with bsd.*.mk, since now they can customize their own builds without the
need to hack bsd.*.mk 

Thanks
--sjg