Date: Tue, 1 Apr 2014 12:57:57 -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: <DBA8EC5A-0C9A-4EED-94CC-178BBAFA29DB@bsdimp.com> In-Reply-To: <20140401162912.7A9D058097@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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 1, 2014, at 10:29 AM, Simon J. Gerraty <sjg@juniper.net> wrote: >=20 > On Tue, 1 Apr 2014 08:22:18 -0600, Warner Losh writes: >>>> re-implement the WITH_* vs WITHOUT_* logic repeatedly. >>=20 >> Where, exactly, do we do this? In my recent gripping I=3D92ve found = almost >=20 > I hit this just about every possible way while trying to support > WITH[OUT]_BMAKE=20 > in such a way that people could build head on 9 etc. > Incluing in-tree bsd.own.mk so MK_BMAKE would get set - broke building > on 9 IIRC. >=20 > Being able to simply do MK_BMAKE?=3D {yes,no} would have been best = solution. >=20 > Also I normally want to built WITH_CTF, but of course you cannot = simply > put that in make.conf you have to=20 >=20 > .if !defined(WITHOUT_CTF) && !defined(NO_CTF) > WITH_CTF=3Dyes > .endif >=20 > else you get errors during build world. That=92s a bug I plan on fixing. But an interesting one because much of = the extra garbage there is due to the duality in the build system where we bogusly = (IMHO) set WITHOUT_CTF on the make command line, plus have an extra special NO_CTF option which does the same sort of thing. Bugs in bmake prevent the simple undefining of certain symbols on the = command line, which makes at least part of the above construct necessary. >>>> It is also generally bad to include bsd.own.mk from sys.mk, which = means >>>> any knobs you need early must re-implement the WITH_* vs WITHOUT_* = logic >>>> repeatedly. >>=20 >> Again, I find no evidence of this in the tree, can you cite specific = exampl=3D >=20 > It isn't done anymore (was certainly done back in 2.x, don't recall = when > it was removed), which is good, but means that sys.mk cannot use > any MK_* that the user can influence via WITH[OUT]_*. =20 > That's not so much a problem for existing options, but makes it > impractical to leverage the mechanism for things you might want to set > during sys.mk - like whether to use meta mode or auto objdir creation. I=92ll have to think about this point. It is a good point, but I=92m = unsure how the proposed changes would fix that. Perhaps you could explain that a = bit. >> I mostly hate this. Specifically, I don=3D92t like the DOMINANT bits. = They ar=3D >> e unnecessary. >=20 > I mostly agree - I find it quite reasonable to simply allow WITHOUT to = win. > DOMINANT_* is just an "out" in case there's some future case I haven't > thought of. The default behavior remains that WITHOUT wins. >=20 >> WITH/WITHOUT is a user-only knob.=20 >=20 > Agreed, but the implementation renders it user unfriendly. > If everywhere I want to set a default (eg make.conf) I have to do a > dance like >=20 > .if !defined(WITHOUT_CTF) && !defined(NO_CTF) > WITH_CTF=3Dyes > .endif >=20 > it isn't exactly helping me as much as it could. > If the build stops using WITH/WITHOUT internally that probably helps. Yea, that=92s just a bug=85 We have severe options like this, but CTF is = one of the more annoying. >> The build system should never use it, but always >> set MK_* directly.=20 >=20 > Agreed - that would be most useful and is one of the main changes in = my > version. Already in the tree. >> I recently fixed it so the build system can start doing =3D >> that. This solves >> the WITH and WITHOUT problem internally. >=20 > That's good - being able to set MK_* directly without causing error > does address the issue for the build itself. >=20 > Alone though it doesn't necessarily make life any better for users > who (per my example above) want to set defaults like > WITH_CTF=3D in make.conf but occasionally override them. Unless they = too > are supposed to set MK_* directly but then what is the point of > WITH[OUT]_* ? Setting defaults in make.conf, and then overriding them is tough because bmake doesn't have a tracking system to know where in the food-chain different variables are set. However, this is also a good point, but I must be being dense to see how your proposal would fix this. >> I'm still not sure I see the big win. >=20 > I have a number of knobs to be set during sys.mk > AUTO_OBJ automatically create objdirs > META_MODE use meta mode objdirs set in sys.mk? I thought that was done bad.obj.mk since it isn=92t= part of the global system. META_MODE might belong there. > setting MK_* is fine, but it is nice if you allow the user to interact > using WITH[OUT]_*, and for that it is best if sys.mk can safely = include > something like options.mk Not sure how creating a new file solves the bsd.own.mk problem, apart perhaps from some name space pollution differences. > Of course the user can learn to MK_AUTO_OBJ=3Dno but that simply = devalues > WITH[OUT]_*=20 >=20 > It is a neat mechanism, that with some minor tweaks could be much more > useful. It is neat and simple now, but the WITH/WITHOUT stuff was neat and = simple when we started and it has devolved as people have hacked on it without proper care. > Baptiste writes: >>> I would be interested in having your opinion on what we did for = ports. >=20 > It is a bit more elaborate (422 lines vs 59 in options.mk) > that's probably a necessity for ports, but not so sure about inclusion > by sys.mk Yea, back to the point I don=92t understand: how is your new file going = to be materially different than the current mechanism. I=92m OK with change, = but I need to understand how the change is going to make things better. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DBA8EC5A-0C9A-4EED-94CC-178BBAFA29DB>