make WITH[OUT]_* more useful?
Simon J. Gerraty
sjg at juniper.net
Tue Apr 1 16:59:48 UTC 2014
On Tue, 1 Apr 2014 08:22:18 -0600, Warner Losh writes:
>>> re-implement the WITH_* vs WITHOUT_* logic repeatedly.
>
>Where, exactly, do we do this? In my recent gripping I=92ve found almost
I hit this just about every possible way while trying to support
WITH[OUT]_BMAKE
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.
Being able to simply do MK_BMAKE?= {yes,no} would have been best solution.
Also I normally want to built WITH_CTF, but of course you cannot simply
put that in make.conf you have to
.if !defined(WITHOUT_CTF) && !defined(NO_CTF)
WITH_CTF=yes
.endif
else you get errors during buildworld.
>>> 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.
>
>Again, I find no evidence of this in the tree, can you cite specific exampl=
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]_*.
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 mostly hate this. Specifically, I don=92t like the DOMINANT bits. They ar=
>e unnecessary.
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.
>WITH/WITHOUT is a user-only knob.
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
.if !defined(WITHOUT_CTF) && !defined(NO_CTF)
WITH_CTF=yes
.endif
it isn't exactly helping me as much as it could.
If the build stops using WITH/WITHOUT internally that probably helps.
>The build system should never use it, but always
>set MK_* directly.
Agreed - that would be most useful and is one of the main changes in my
version.
>I recently fixed it so the build system can start doing =
>that. This solves
>the WITH and WITHOUT problem internally.
That's good - being able to set MK_* directly without causing error
does address the issue for the build itself.
Alone though it doesn't necessarily make life any better for users
who (per my example above) want to set defaults like
WITH_CTF= 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]_* ?
>I'm still not sure I see the big win.
I have a number of knobs to be set during sys.mk
AUTO_OBJ automatically create objdirs
META_MODE use meta mode
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
Of course the user can learn to MK_AUTO_OBJ=no but that simply devalues
WITH[OUT]_*
It is a neat mechanism, that with some minor tweaks could be much more
useful.
Baptiste writes:
>> I would be interested in having your opinion on what we did for ports.
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
More information about the freebsd-arch
mailing list