Today at work, I was thinking over my next agenda with tmk, namely implementing the checksum based method of checking whether or not targets are up to date, and recipe caching.

Implementing the checksums are actually pretty easy, the hardest part is just adding a command line option and a method for changing the checksum algorithm to be used.

Doing the cache on the other hand, is a bit more ‘thought’ required in the solving. Because tmk currently does variable expansions on rules, it’s impossible to correctly cache for any rule or variable assignment involving an environment variable. The principal reason for the variable expansions, was so to help ensure the uniqueness of a rule. So obviously, the proper thing to do is to delay the variable expansions until they are needed, there by making the data store completely cacheable.

The obstacle of course, is that rule definitions can no longer have the chance to be a way in which the rules become unique, which rules out the possibility that variable assignments can occur after the top level: which encourages me to push the spec in the direction I had originally planned. Another option, would be to just leave it as is, and note the issue around environment variables in the manual. Of course, a third possible solution is making the processing step more aware of line numbers.

Since I’d rather have it that way, I’m opting for the first: delaying the variable expansions so that the entire result of the parsing phase can be cached.

I also feel like a chicken with it’s head cut off atm :-S