Config language progress/issues...

Eric W. Biederman ebiederman at
Wed Feb 4 18:21:39 CET 2004

ron minnich <rminnich at> writes:

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

Right, and the version I have and I just committed to the public tree
does delayed evaluation for everything but if statements.  I think
delayed evaluation is a fine technique.
> > 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.
That is how I view the configuration files as well.  The problem is
that there are some options I can't move.

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

To be clear the are in generic configuration files included by but the behaviour is the same.
> 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.

The delayed evaluation is fine with me.  But Pascal and Modual-X use
delayed evaluation in the one pass model.  They don't actually run
the program they compile in that first pass :)  Even C can
be compiled in a single pass.

Right now everything works but if statements.  

The parser could easily pass the conditionals into the statements that
are conditional on if's.  The challenge is simply manipulating those
constants.  If if statements did not nest it would be a much simpler


More information about the coreboot mailing list