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

[Taylor R Campbell <campbell+netbsd-source-changes-d%mumble.net@localhost>]

   Date: Fri, 31 Oct 2014 03:36:45 +0900
   From: Masao Uebayashi <uebayasi%gmail.com@localhost>

   On Fri, Oct 31, 2014 at 1:49 AM, David Holland
   <dholland-sourcechanges%netbsd.org@localhost> 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.)