Date: Wed, 9 Apr 2014 15:13:32 -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: <5D9BD168-D7E5-477E-AEA3-47B24445C89F@bsdimp.com> In-Reply-To: <20140402212328.7CE8958097@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>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Simon,
Sorry to take a week to reply. Other things came up and it slipped my =
mind until now.
It sounds like we=92re in agreement on how to proceed, or very nearly =
so. I have some more
comments below, but I think the next order of business would be patches. =
Do you have
some ready to roll? If so, then we should iterate on them. If not, I can =
find some time over
the coming days/weeks. I=92d like to have this done before BSDcan, but =
if not we can
chat then, assuming you are going.
On Apr 2, 2014, at 3:23 PM, Simon J. Gerraty <sjg@juniper.net> wrote:
>>> which are needed during sys.mk can be influenced by user's =
-DWITH[OUT_*
>>=20
>> OK. A bit of a contrived example, but I suppose if I understood the =
meta mo=3D
>> de
>=20
> 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.
Makes sense...
>> a bit better I might think differently :)
>>=20
>> I=3D92m a bit hesitant, though, to have this affect sys.mk because =
that affec=3D
>> ts all users
>> of make, not just /usr/src.
>=20
> 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/
That=92s a bit of a departure over how we=92ve done things, but one that =
may make
a good amount of sense. Where would the src build pick this up from if =
it isn=92t
installed?
>> 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=3D92s more of a mix, I=3D92m less sure.
>=20
> Agreed, that's why I took the easy way out by allowing the winner to =
be
> configured if the need should arise ;-)
>=20
>>> Traditionally done in bsd.obj.mk - but that requires a separate
>>> invocation of make.
>>=20
>> Right, but can=3D92t that be done automatically w/o that extra =
invocation?
>=20
> Yes provided you do it early enough (ie during sys.mk)
> eg. before you've evaluated things that affect .PATH
Ah, I was aware of that restriction.
>> Back to the NO_CTF stuff I talked about above: I totally get this. If =
you l=3D
>=20
>> There=3D92s one place in the tree that wants to turn off CTF. This is =
mostly =3D
>> fixed by
>> just setting MK_CTF=3D3Dno in that makefile after we include =
bsd.own.mk. I say
>=20
> Wouldn't it be simpler to set MK_CTF=3Dno *before* including =
bsd.own.mk ?
Well, kinda=85 Then the issue becomes, in what I think you are =
proposing, what happens
to the meta variables, or MK_foo that sets a lot of MK_bar. Assuming we =
move all of
them to their own file, we have two sections. One that sets MK_xxx =
variables based on
WITH/WITHOUT, and a second one that sets them based on other MK_xxx =
variables.
If I set MK_CTF=3Dno in my makefile, and it caused other MK_ flags to be =
set, then I=92d have
to include something to take another run at setting those =
meta-variables.
>> 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=3D92t completely work, it still =
shows
>> up as defined) and set WITHOUT_CTF before bsd.own.mk and it would =
work,
>> modulo this bug.
>>=20
>> This can really only be fixed by making bsd.own.mk look more like
>>=20
>> # section 1 -same
>> .include <bsd.options.mk>
>> # section 3 - same
>>=20
>> with bsd.options.mk looking a lot like section 2 of bsd.own.mk. =
Also, we=3D
>> =3D92d have
>=20
> Yes, that's essentially what I was proposing.
> By extracting the mechanism to its own file, it can be re-used.
Do you have patches? I think I like it...
>> This sounds a lot like what you=3D92re 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
>=20
> 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.
Yes. I can=92t fix MK_CTF without a fix due to side effects.
>> be able to get away with it in sys.mk, I=3D92m hesitant to place it =
in there =3D
>> because
>> that=3D92s global to everything, including ports, etc. Plus, I think =
it is to=3D
>=20
> 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.
I thought ports used a different mechanism and defined special magic so =
the
src tree mechanism was disabled.
>> o early, due to meta MK_ variables, that I talk about below.
>=20
>>> .if defined(MK_${var})
>>> .if ${.MAKE.LEVEL} =3D3D=3D3D 0
>>> .error MK_${var} can't be set by a user.
>>> .endif
>>> =3D
>>=20
>>> would seem to negate that. Why can a makefile at level 0 not set =
MK_*?
>>=20
>> 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=3D
>=20
> Setting MK_* before bsd.own.mk vs after has semantic differences
> but that shouldn't preclude doing either.
>=20
> Eg. the knob names below describe the semantics
>=20
> # these remove choice from user
> MK_CANNOT=3D no
> MK_MUST=3D yes
>=20
> .include <bsd.own.mk>
>=20
> # these respect user choices
> MK_LIKE?=3D yes
> MK_DISLIKE?=3D no
>=20
>> But there=3D92s a problem even if we take the approach above. Section =
2 in bs=3D
>> 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=3D3D=3D3Dno turning of OpenSSL, =
Kerberos,=3D
>> etc). If
>> you wanted to set one of those variables in your Makefile, you=3D92d =
have a c=3D
>> hicken
>> and egg problem. If you set it before bsd.options.mk, then you=3D92d =
get the =3D
>> cascade effects
>> but hit the warning. If you set it after, you dodge the warning, but =
don=3D92=3D
>> t get the cascade.
>=20
> 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_*
>=20
> If that has cascading effects, we assume they are intended.
>=20
> Currently, what warning do you hit btw?=20
> I only see .errors if MK_* is pre-defined or WITH[OUT]* both defined.
Those errors, although many have been corrected...
>> This problem suggests, perhaps, that the test be deleted.
>>=20
>>> The outstanding question is dealing with conflict when both WITH_FOO =
and
>>> WITHOUT_FOO are defined.
>>=20
>> True. That=3D92s a tougher problem than you might think on first =
blush, as we=3D
>> =3D92ve
>> been talking about. For now, I=3D92d suggest WITHOUT wins, and we see =
how far
>=20
> 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.
I=92m agnostic on a mechanism to declare winners. If we can do the rest =
easily w/o
it I don=92t care. If it is just a couple of lines to add, I won=92t =
complain.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5D9BD168-D7E5-477E-AEA3-47B24445C89F>