[jamming] HDRGRIST

[Ingo Weinhold]

On 2007-05-14 at 03:20:18 [+0200], matthew conte <matt at baisoku.org> wrote:
> I encountered a dependency issue in our build system recently. We have a
> system whereby Scheme-based object descriptions are used to generate C++
> header files; these header files are then used to build several
> libraries and applications under a single source tree. Occasionally,
> code changes in the object descriptions would not retrigger source
> rebuilds in one particular application, leading to link errors.
> 
> Probing a littler further into this, it appears the issue was caused by
> multiple identically-named header files in different physical locations;
> in this case, the name of the file was "StdAfx.h". Different copies of
> this file in different locations had different #includes, causing only
> one of the files' dependency graphs to be bound internally in Jam for
> the name "StdAfx.h".
> 
> Briefly scanning Jambase, i found that HDRGRIST, when set, would seem to
> solve the issue. I ran some quick tests, adding a rule which set
> HDRGRIST = $(SOURCE_GRIST), piggy-backed this off of SUBDIRRULES, and it
> seemed to solve all of my problems.
> 
> So i guess my question is, why is HDRGRIST unset in Jambase? What
> horrible corner case am i creating by setting this? I can't seem to
> reason through any drawback to this addition.

I do vaguely recall that there were only performance reasons for not 
setting the header grist. Something like the same header needing to be 
scanned for each subdir it is included from (since for each subdir it has a 
different target name). I might be wrong though. However it is generally 
advisable to use the "header cache" patch (don't have a pointer right now, 
but it was in the public depot). It not only speeds up subsequent header 
scanning, it also sets HDRGRIST and thus works more correctly.

CU, Ingo