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

[Masao Uebayashi <uebayasi%gmail.com@localhost>]

On Thu, Oct 30, 2014 at 10:01 PM, Quentin Garnier <cube%cubidou.net@localhost> wrote:
> 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).

OK, my example was confusing, I meant module (attribute-as-module) by
"options FOO".  Because config(1) has had no way to directly select a
module, I abused/extended "options" to select a module.  I'm reverting
it and adding a generic "select" directive which selects a specified
module and its dependency modules.

For options, you're right, options (flags/params) don't have
dependency.  I don't mean to extend it too.  I try to address apb@'s
item.

> 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.

I don't fully understand the device part (especially "no" behavior),
but I assume they basically expect things are already defined, right?

> 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.

I don't mean to make "defopt" (flags/params) to be like "define".
(Said so in TODO.)

I mean to make "device" (and hopefully "attach") to be more like
"define" though.