On Thu, Oct 30, 2014 at 10:01 PM, Quentin Garnier <c...@cubidou.net> 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 <a...@netbsd.org> 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.
