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 Config.lb because their if statements reside in src/config/Config.lb which is processed before src/mainboard/.../.../Config.lb. 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 Config.lb 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.
ron