Date: Thu, 17 Apr 2014 15:06:33 -0700 From: "Simon J. Gerraty" <sjg@juniper.net> To: Warner Losh <imp@bsdimp.com> Cc: Baptiste Daroussin <bapt@freebsd.org>, freebsd-arch@freebsd.org, sjg@juniper.net Subject: Re: make WITH[OUT]_* more useful? Message-ID: <20140417220633.242585809F@chaos.jnpr.net> In-Reply-To: <7C527DA8-ABC0-4D6A-AACB-64D89246B569@bsdimp.com> References: <20140401051327.F20F958097@chaos.jnpr.net> <20140401064316.GQ99393@ivaldir.etoilebsd.net> <766EFF76-7B41-423F-B447-DBA25BD14470@bsdimp.com> <20140401162912.7A9D058097@chaos.jnpr.net> <DBA8EC5A-0C9A-4EED-94CC-178BBAFA29DB@bsdimp.com> <20140401195249.8752258097@chaos.jnpr.net> <2349B38E-F6F2-4911-92F2-3D62FCBD73DA@bsdimp.com> <20140402212328.7CE8958097@chaos.jnpr.net> <5D9BD168-D7E5-477E-AEA3-47B24445C89F@bsdimp.com> <20140410034645.C058658097@chaos.jnpr.net> <DC1B53C9-AF5F-4CF7-A369-5881C71E7F77@bsdimp.com> <20140417063437.3BBF85809E@chaos.jnpr.net> <06CC1B46-2BF2-439C-8F97-16EA8DD7805C@bsdimp.com> <20140417181159.0EFEA5809E@chaos.jnpr.net> <7C527DA8-ABC0-4D6A-AACB-64D89246B569@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140417220633.242585809F>