Config language progress/issues...

ron minnich rminnich at
Wed Feb 4 15:11:01 CET 2004

On 4 Feb 2004, Eric W. Biederman wrote:

> Earlier tonight I ran into some silly stupid problems where defaults were
> overriding options and now that those are fixed I have committed the working
> config.g

I think there is a simpler fix to that. We had talked about making all 
options deferred evaluation, i.e. not evaluted until used. I think this 
might have helped with many of these problems. 

> In particular the following options must be placed in the outermost
> because their if statements reside in src/config/
> which is processed before src/mainboard/.../.../  The problem
> is that is too soon to know the if condition unless everything is set in
> the top level config file.

I see your point. Part of this is different thinking about the role of the 
various files. 

As the tool evolved we somehow ended up with lots of stuff in the target
file (you call it the outermost config file) which is not really ideal. To
me, the right place for most of the stuff is the mainboard file.  That's
actually how the earlier config tool ended up working. Target files
represent a specialization of the mainboard file, and some options may
change, but as we have all seen putting it all in the target file is high
maintenance, since a simple change to a mainboard propagates through all
the target files.

The present of an 'if' in is something interesting, which I
admit I had not anticipated.

OK, more looking. I know you have advocated a 2-pass tool, and you know I
am not convinced for the need; I figure if Pascal and Modula-X can run
one-pass, a simple Config tool should be able to as well. But we'll talk 
more here.


More information about the coreboot mailing list