+1 for design

I've just fixed the bug about tmk reporting the wrong filename when an included file contains an error. The thing that makes me smile, is because I designed the recipe parsing and processing code reasonably well, making that work correctly was trivial. At worst, I expected that I would have to modify the Recipe class to incorporate a separate data stack into the parser, but not even that was necessary. Most changes were (as hoped) just refining the data structures used for storage.

tmk is pretty simple, it does two passes at a recipe:

• First it parses the recipe into an internal data store, most serious (e.g. syntax) errors are reported here. A minimal level of evaluation is done, namely we need to do some expansions or you can't use variable substitutions when defining a rule.
• Secondly, it walks through the data store at processing time (e.g. doing the magic), conducts final expansions when needed, and carries out its mission in life.

One reason I chose the syntactic style that I did for tmk, it is both visually straight forward, and easy to code around. I like simple but effective, when it works.

My next (and real) task, will likely be making the rules relational to one another, exempli gratia to topologically enqueue rules in dependency order. Right still tmk is limited to sequentially executing the rules. That's actually good *enough*, but I'd rather have that tidbit taken care of by tmk, then having to address it in the recipe construction.

I must admit however, that adapting isnewer() by way of it's cmpfunc parameter, to cope with using file checksums instead of modification times, will be fun to implement :-D.