...

I believe that the original Jam scans each target. If a header is represented in the dependency graph more than once via grist, its scanned more than once. In your example, if there is nothing fancy going on with grist, the header is scanned only once. In a system the size you are mentioning, you'll probably need grist to make target names unique, in which case each combination of grist+file would be scanned.

With the cache in place, each physical file is only scanned once. The cache uses the boundname of the header.

I can't speak for why Christopher made this decision, but I'm glad he did! I would mention: portability, simplicity as being the small obvious reasons. The real reason would be that the results of the scan are needed before the dependency graph can be run - its needed before any of the compiles start up. The header dependencies determine the order of the graph which is critical to the way jam works.

I don't know of a way to set a Jam variable to the result of a command you run. We needed a similar thing though. What we do is combine some perl/sh in our build, and create a series of files with the info we need. On compile lines, if you need that info, either use something like: CC -o foo -set_version `cat .version` or create a header and include it. There are usually ways around it.