Source-Changes-D archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: src/usr.bin/config



On Thu, Oct 30, 2014 at 09:27:06PM +0900, Masao Uebayashi wrote:
> On Thu, Oct 30, 2014 at 8:36 PM, Alan Barrett <apb%netbsd.org@localhost> wrote:
> > On Thu, 30 Oct 2014, Masao Uebayashi wrote:
> >>
> >> What do you expect by doing:
> >>
> >>  options FOO
> >>  no options FOO
> >>  options FOO
> >
> > I expect it to be equivalent to just one "options FOO".
> >
> > The "no options FOO" in line 2 should cancel the "options FOO" in line 1,
> > and then the "options FOO" in line 3 should put it back.
> >
> > In the cases that I care about, the "options" and "no options" lines will be
> > in different files, referenced via "include" directives.
> 
> So, while you expect that "options" works before it's defined, you
> also expect the order is honored for "no" use.  I'm not sure how it
> can work internally.
> 
> At this moment, "no" are evaluated when it's parsed.  Those "no agp*"
> fallouts happened because agp is re-selected while resolving
> dependency after all parsing is done.  IMO anything relying on order
> tends to be broken by design.  For example: if BAR depends on FOO, "no
> options FOO" has to disable BAR too, because BAR can't be enabled
> without FOO.  But when you re-enable FOO, BAR is not enabled.  Is this
> really what you're expecting?

I don't know how it is right now, but options didn't use to depend on
other options so with "options" the case is moot and I would expect the
behaviour Alan describes as correct (this is how it worked the last time
I touched config(1), or at least, was meant to work).

For devices, I spent quite a bit of effort making sure "no" behaved the
way Alan expects it.  For instance:

include "GENERIC"

this* at pci? dev ? fun ?
no device pci
that* at pci? dev ? fun ?

would emit an error for "that*" but not for "this*".  Moreover, without
the last line, none of "this*" or anything pci-related in GENERIC would
actually be selected.

So if you start making defopt more equivalent to define and allow
"options BAR" to depend on "options FOO", then I would expect
"no options FOO" to cancel a previous "options BAR".

Otherwise defopt and define used to have very different semantics.

-- 
Quentin Garnier - cube%cubidou.net@localhost
"See the look on my face from staying too long in one place
[...] every time the morning breaks I know I'm closer to falling"
KT Tunstall, Saving My Face, Drastic Fantastic, 2007.

Attachment: pgp8fejYWrAyo.pgp
Description: PGP signature



Home | Main Index | Thread Index | Old Index