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>