At some point in the past Greg gave me a version of config.g to test. I reported success but it never got merged, but I have been using it...
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
There is still one huge remaining bug though. If statements are evaluated too early.
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.
option HAVE_OPTION_TABLE=1 option HAVE_FALLBACK_BOOT=1
Eric
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
ron minnich rminnich@lanl.gov 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 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.
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 Config.lb is something interesting, which I admit I had not anticipated.
To be clear the are in generic configuration files included by Config.lb 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 problem.
Eric
-
ebiederman＠lnxi.com -
ron minnich