make WITH[OUT]_* more useful?

Simon J. Gerraty sjg at juniper.net
Thu Apr 17 22:07:01 UTC 2014


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.

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

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

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

You can still support {src,local,make}.conf

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

Thanks
--sjg



More information about the freebsd-arch mailing list