make WITH[OUT]_* more useful?

[Warner Losh]

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

> 
> On Thu, 17 Apr 2014 14:29:28 -0600, Warner Losh writes:
>>> bsd.own.mk -> bsd.srcopts.mk -> bsd.mkopts.mk
>> 
>> Since we=92re planning a src.opts.mk at some point (to control /usr/src bui=
>> lds),
>> the bsd.srcopts.mk name seems to have a short shelf life. Maybe just bsd.op=
>> ts.mk?
> 
> Sure bsd.opts.mk sounds fine.

Done.

>>> .-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=92t 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.
> 
> I've avoided that issue for ages by using a wrapper script to condition
> the env for the tree I'm working in, junos freebsd, netbsd etc.
> If all your trees have a share/mk, that you want to use you can just 
> export MAKESYSPATH=".../share/mk"
> and bmake will DTRT.

Can that be set in a Makefile?

>>> 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?
> 
> It depends.  Some things need to be done after Makefile has been read
> (rather than before) - eg any variable ref on rhs of dependency rule
> needs to have a value at that time.
> 
> Let's say I wanted to be able to build head in meta mode (rather than
> keep syncing to projects/bmake).
> If there were suitable local.*.mk hook points I could do that without
> affecting anyone else, until such time as I can convince others that its
> a brilliant idea ;-)
> 
> Even if FreeBSD.org decide they want to build /usr/src in
> meta mode, that doesn't mean that every user of FreeBSD wants all their
> own projects to build that way.  Some of the glue I had in local.*.mk
> could move to src.*.mk so that /usr/src could leverage it without
> impacting every user of bsd.*.mk
> 
> That's just one example of course.

OK. I’m sold.

>> Also missing is a defined place for users to define WITH/WITHOUT_FOO.
> 
> You can still support {src,local,make}.conf

OK. Will keep it around.

>> 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.
> 
> I'm not sure it would impact one way or the other.
> It all boils down to whether /usr/share/mk, -m * or $MAKESYSPATH
> are used.
> 
> I would figure anyone inclined to go adding local.*.mk to their tree,
> would be able to cope with setting MAKESYSPATH or whatever else it takes
> to do what they want.

Yea, I agree for local.*.mk, but the case is less clear for src.*.mk which is
now required for the build… I should do a census on the number of files this affects.

I’ll post patches as soon as I finish make universe.

Warner