Boost logo

Boost-Build :

From: Alexey Syomichev (asyomichev_at_[hidden])
Date: 2005-05-03 16:04:42

I believe that header dependency scanning results used to be cached
between bjam runs. I also remember that at some point the caching was
disabled because it didn't show any speed advantage over re-scanning.
Is this really the case for any level of the performance of a file
system hosting the project?
I think I might have a case when caching would be beneficial. I have a
relatively large project living on a relatively slow NFS system. For a
build started from the root of the project, it takes about 3
(frustrating) minutes of "...patience..." before the first update
action command, and bjam finds about 34000 targets.
The output of "bjam –d+10", sorted by the net time, shows
that the header scanning takes a significant portion of that time (see
Is it hard to put header dependency information caching back?
Also, in my case a large number of 3rd party headers account for about
3/4 of targets found by bjam, and for about 2/3 of scanning time. A
feature that would allow excluding certain directories from header
dependency scanning would be extremely useful. Does anybody else share
this opinion?

Here is the top portion of sorted bjam –d+10:
gross net # entries name
19072000 8126000 25588 class_at_c-scanner.process
5506000 4821000 51176 regex.transform
4431000 4431000 25588 scanner.propagate
3959000 3959000 50183 feature.valid
2875000 2875000 716 CHECK_IF_FILE
44618000 2650000 152 modules.load
6376000 2484000 1584 class_at_property-set.__init__
2272000 2272000 2492 GLOB
20807000 1735000 25588 scanner.hdrrule
1403000 1403000 296682 MATCH
10502000 1169000 9491
4795000 965000 48771 feature.attributes
1166000 962000 8364 regex.split


Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at