Date: Thu, 17 Apr 2014 14:29:28 -0600 From: Warner Losh <imp@bsdimp.com> To: "Simon J. Gerraty" <sjg@juniper.net> Cc: Baptiste Daroussin <bapt@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: make WITH[OUT]_* more useful? Message-ID: <7C527DA8-ABC0-4D6A-AACB-64D89246B569@bsdimp.com> In-Reply-To: <20140417181159.0EFEA5809E@chaos.jnpr.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 17, 2014, at 12:11 PM, Simon J. Gerraty <sjg@juniper.net> wrote:
>=20
> On Thu, 17 Apr 2014 10:30:58 -0600, Warner Losh writes:
>> This was step one: separate out the options processing from the =3D
>> bsd.own.mk stuff.
>> Having a few lines that are generic would be nice to include. I=3D92d =
like =3D
>> to go ahead and
>> commit step 1, even if we refine things a bit later to keep the =
change =3D
>> sets manageable
>> and under control=3D85 Is that reasonable? It will help other areas =
and we =3D
>> don=3D92t need to
>> do much more than settle on filenames. :)
>=20
> 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=92re 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=92d like to do the above tweak. There=92s on conflict with ports and =
the name seems
better.
>>> Sorry, which file are you talking about?=3D20
>>=20
>> My bsd.srcopts.mk was what I was talking about here needing to be =
added =3D
>> to share/mk/Makefile.
>=20
> 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).
>=20
> 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=92s different than today=92s 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 =3D
>> the
>>> pattern local.* or src.* doesn't get installed.
>>> Hopefully that shouldn't surprise anyone either.
>>=20
>> IF we can achieve that separation, then great.
>=20
> Yep.
I=92ll start down that path once we have the above stuff done.
>>> To restate that slightly differently, you can think of these things =
as =3D
>> a
>>> hierarchy:
>>> =3D20
>>> bsd.* mechanism for building stuff (not just /usr/src)
>>> src.* stuff just for building /usr/src
>>> local.* local tweaks to all the above
>>=20
>> Yes, as long as the MK_FOO variables that are really src building =
stuff =3D
>> don=3D92t
>> infect the bsd.foo.mk files, this could work out.=20
>=20
> Exactly. =20
>=20
> 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=85 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 =3D
>> Makefiles
>=20
> I'm not sure that would be necessary.
> Having to support lots of active branches makes me leery of gratuitous
> changes ;-)
Yea. I=92d hoped you=92d 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
>=20
> .-include "src.sys.mk"
> .-include "local.sys.mk"
>=20
> 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.
> Similarly, bsd.init.mk doing
>=20
> .-include "src.init.mk"
> .-include "local.init.mk"
>=20
> would allow for customization of things to be done after Makefile has
> been read.=20
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=20
> 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=20
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7C527DA8-ABC0-4D6A-AACB-64D89246B569>