From: Toon Knapen (toon.knapen_at_[hidden])
Date: 2004-04-29 08:11:17
Rene Rivera wrote:
> Good news is that bjam should already be doing this for you. Look for a
> file ".jamdeps", that holds a cache of all the depency scanning.
Apparantly this is stored in the ALL_LOCATE_TARGET/bin directory, right?
But how can you know if you need to update it or not. For instance
'make' will not regenerate the dependency tree which is only regenerated
when 'make depend' is called.
So how can I explain to bjam to use the cached .jamdeps file instead of
regenerating the dependencies again.
> The bad news is that the slow startup has nothing to do with dependency
> scanning. But has everything to do with parsing and generating the
> actual target descriptions. It's a know problem for which we don't have
> a real solution. Bjam spends much time building many strings, as all the
> work it does is based on string and lists of strings. Boost.Build uses
> *many* strings and does *many* operations on them. Which results in a
> large memory use because bjam considers strings read-only, and doesn't
> ever collect unused strings (for various C reasons).
> And we don't currently have a way to improve the situation. Ideas are
> welcome ;-)
memory pool or storing the state after the dependency generating and
rule expansion (~ precompiled headers) but of course that's easy to say
but a lot harder to implement, I realise that.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk