On Wed, 29 Oct 1997 chri...@natinst.com wrote:

This is for my fund of knowledge. I offer no insights here. Quit now if your not curious....

My reading in the doc of why this happens is that 1. Jam parses the Jamfiles, 2. which creates a data structure with all the sources/targets in it, 3. does some filesystem exploration to figure out which targets need to be rebuilt, and 4. from that, and that only, starts running commands to make that happen.

So when jam parsed the Jamfile, common.o got put in the structure twice. When the exploration happened, both copies were marked (because they "both" needed updating), and the commands to update it were run twice because it was in the data structure twice.

A. Can anybody who's more familiar with the internal workings of Jam correct that (vague) summary of whats really going on, or is that about how it works out?

B. It doesn't make sense to me to re-update that internal tree every time you update a target - it would solve the problem, but performance would go straight down the tubes.

It might make sense to correct the fact that jam sees each common.c/common.o as a separate entity (thus it would get on the data structure just once, and would be built just once.)

But, knowing a little of the history of Jam, I'm betting there's a good reason NOT to do that. Can you tell me what it is? (Jam's not "young" and I'm sure this has come up before. Since it wasn't changed/added, there must have been a reason).