Date: Wed, 2 Apr 2014 14:23:28 -0700 From: "Simon J. Gerraty" <sjg@juniper.net> To: Warner Losh <imp@bsdimp.com> Cc: Baptiste Daroussin <bapt@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: make WITH[OUT]_* more useful? Message-ID: <20140402212328.7CE8958097@chaos.jnpr.net> In-Reply-To: <2349B38E-F6F2-4911-92F2-3D62FCBD73DA@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>
next in thread | previous in thread | raw e-mail | index | archive | help
>> which are needed during sys.mk can be influenced by user's -DWITH[OUT_*
>
>OK. A bit of a contrived example, but I suppose if I understood the meta mo=
>de
Actually not contrived at all - we have that internally.
Ie. we have a local.sys.mk to set all our cool stuff
but we currently just test for .ifdef WITH[OUT]*, hence this thread.
>a bit better I might think differently :)
>
>I=92m a bit hesitant, though, to have this affect sys.mk because that affec=
>ts all users
>of make, not just /usr/src.
That's why I'd put such things in local.sys.mk or some other makefile
that affects /usr/src but isn't install into /usr/share/mk/
>In some cases, you can declare a winner. In other cases that might be harder
>to do. With almost all options defaulting to YES, having WITHOUT win makes
>good sense. When there=92s more of a mix, I=92m less sure.
Agreed, that's why I took the easy way out by allowing the winner to be
configured if the need should arise ;-)
>> Traditionally done in bsd.obj.mk - but that requires a separate
>> invocation of make.
>
>Right, but can=92t that be done automatically w/o that extra invocation?
Yes provided you do it early enough (ie during sys.mk)
eg. before you've evaluated things that affect .PATH
>Back to the NO_CTF stuff I talked about above: I totally get this. If you l=
>There=92s one place in the tree that wants to turn off CTF. This is mostly =
>fixed by
>just setting MK_CTF=3Dno in that makefile after we include bsd.own.mk. I say
Wouldn't it be simpler to set MK_CTF=no *before* including bsd.own.mk ?
>mostly fixed because we wind up with a NULL command where we really want
>a @: command, though the former I believe is harmless but verbose. Except
>one could unset WITH_CTF (which doesn=92t completely work, it still shows
>up as defined) and set WITHOUT_CTF before bsd.own.mk and it would work,
>modulo this bug.
>
>This can really only be fixed by making bsd.own.mk look more like
>
># section 1 -same
>.include <bsd.options.mk>
># section 3 - same
>
>with bsd.options.mk looking a lot like section 2 of bsd.own.mk. Also, we=
>=92d have
Yes, that's essentially what I was proposing.
By extracting the mechanism to its own file, it can be re-used.
>This sounds a lot like what you=92re trying to describe, though placement of
>bsd.options.mk may be different than I described. The only reason we
>need it where I suggested it is compatibility with the past. Though we may
Yes I assumed it would be included as above - to avoid changing behavior
unnecessarily. Note: tweaking the semantics and making it re-usable are
somewhat orthogonal.
>be able to get away with it in sys.mk, I=92m hesitant to place it in there =
>because
>that=92s global to everything, including ports, etc. Plus, I think it is to=
Calling it bsd.options.mk is a conflict with ports.
Though including it as "bsd.options.mk" both in bsd.own.mk and in the
relevant ports makefile, should probably mitigate that.
>o early, due to meta MK_ variables, that I talk about below.
>> .if defined(MK_${var})
>> .if ${.MAKE.LEVEL} =3D=3D 0
>> .error MK_${var} can't be set by a user.
>> .endif
>> =
>
>> would seem to negate that. Why can a makefile at level 0 not set MK_*?
>
>Well, the notion now is that if you want to test MK_* variables, you need to
>include bsd.own.mk first. The notion I was going for with the above is that=
Setting MK_* before bsd.own.mk vs after has semantic differences
but that shouldn't preclude doing either.
Eg. the knob names below describe the semantics
# these remove choice from user
MK_CANNOT= no
MK_MUST= yes
.include <bsd.own.mk>
# these respect user choices
MK_LIKE?= yes
MK_DISLIKE?= no
>But there=92s a problem even if we take the approach above. Section 2 in bs=
>d.own.mk
>is actually two separate sections. One that sets the MK_* variables based on
>WITH_ or WITHOUT_ and then a second section that cascades the MK_ variables
>to other MK_ variables (like MK_CRYPT=3D=3Dno turning of OpenSSL, Kerberos,=
> etc). If
>you wanted to set one of those variables in your Makefile, you=92d have a c=
>hicken
>and egg problem. If you set it before bsd.options.mk, then you=92d get the =
>cascade effects
>but hit the warning. If you set it after, you dodge the warning, but don=92=
>t get the cascade.
Per above setting MK_* before including bsd.own.mk is just supressing
user input, probably not something to do a lot, but handy at times -
eg. allows doing away with NO_*
If that has cascading effects, we assume they are intended.
Currently, what warning do you hit btw?
I only see .errors if MK_* is pre-defined or WITH[OUT]* both defined.
>This problem suggests, perhaps, that the test be deleted.
>
>> The outstanding question is dealing with conflict when both WITH_FOO and
>> WITHOUT_FOO are defined.
>
>True. That=92s a tougher problem than you might think on first blush, as we=
>=92ve
>been talking about. For now, I=92d suggest WITHOUT wins, and we see how far
Agreed. I cannot currently think of a case where that wouldn't be
right, but as I mentioned wrt my options.mk it is easy to allow
configurability should the need arise.
Thanks
--sjg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140402212328.7CE8958097>