make WITH[OUT]_* more useful?

[Warner Losh]

On Apr 17, 2014, at 12:11 PM, Simon J. Gerraty <sjg at juniper.net> wrote:

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

Since we’re planning a src.opts.mk at some point (to control /usr/src builds),
the bsd.srcopts.mk name seems to have a short shelf life. Maybe just bsd.opts.mk?

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

I’d like to do the above tweak. There’s on conflict with ports and the name seems
better.

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

Yea, I think both of the above files, regardless of name, should be installed.
They just allow things to be configured, without providing a place to configure
them (well, without a place that’s different than today’s policy of /etc/src.conf
unless overridden).

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

I’ll start down that path once we have the above stuff done.

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

Yes.

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

I think so, yes.

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

Yea… There may be some contamination in user Makefiles today, but
that should be minimal and will be easy to eradicate.

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

Yea. I’d hoped you’d say that. We build individual programs/libraries with the bsd.*.mk
files only, in general, although there may be some exceptions that are carefully called
out and those exceptions would only be to the extent of including the src.opts.mk files.

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

In non-posix mode, sure. This would be the natural place for
the MK option setting. While it is early, it isn’t too bad. It works
great for buildworld scenarios, since we have a well-defined
location for src.sys.mk. It works less well for the individual src
Makefiles that might need to access variables set in src.sys.mk,
which becomes unfindable w/o extra args on the command line,
or requires knowledge of where the Makefile lives in the tree
to reach over and snag it.

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

What would go there? Or would they be empty place holders?

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

I both like and dislike that notion :) I more like than dislike it for the bin/Makefile
case (my only objection being it 

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

Also missing is a defined place for users to define WITH/WITHOUT_FOO.

> 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 

True, but it looks like it may make in-tree use in the non-build-world case more
complicated. There may be some resistance to that.

Warner