HDRGRIST

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.

Regards,
--Matt.
_______________________________________________
jamming mailing list  -  jammingperforce.com
http://maillist.perforce.com/mailman/listinfo/jamming

On 2007-05-14 at 03:20:18 [+0200], matthew conte
<mattbaisoku.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
_______________________________________________
jamming mailing list  -  jammingperforce.com
http://maillist.perforce.com/mailman/listinfo/jamming