Date: Fri, 31 Oct 2014 03:36:45 +0900 From: Masao Uebayashi <uebay...@gmail.com>
On Fri, Oct 31, 2014 at 1:49 AM, David Holland <dholland-sourcechan...@netbsd.org> wrote: > On Thu, Oct 30, 2014 at 09:27:06PM +0900, Masao Uebayashi wrote: > > 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 think it's important not to break the semantics of this. Sure, but this makes me rather depressive. It seems to me that while depending on ordering for definitions, files, &c., may be no good, for selections the language of include "GENERIC" no options DIAGNOSTIC no agp* is still valuable. So config(1) ought to choose whatever is the last yes/no answer for a selection in order to decide what things are really enabled or disabled, and then process dependencies recursively from there, rather than incrementally processing dependencies as the parser makes progress. (But I've only been vaguely following from the sidelines, so feel free to disregard me if that doesn't make any sense given how config(1) works.)
