job000038

miklos_fazekas (Miklos Fazekas)
Miklos Fazekas created this job , modified by Lester Cheung
Closed
This bug is a generalization of the bug submitted by
http://maillist.perforce.com/pipermail/jamming/2001-December/001481.html

There's a test case in
jam -f //guest/miklos_fazekas/jamfix/testcases/recursiveontarget/Test.jam

There's another more complicated test in:
jam -f //guest/miklos_fazekas/jamfix/testcases/recursiveontarget/Test2.jam

I think that the current behaviour see http://maillist.perforce.com/pipermail/jamming/2001-December/001481.html for the worst case,
is not acceptable.

There's a fix in change 2529
This fix will makes the variables bound to t read only as globals when promoted to globals. This makes the following program produce different results with Jam 2.4 (output is 2) and Jam2.5 (output is 1)

rule SetGlobal {
  $(<) = $(>) ;
}
P on T = 1 ;
on T SetGlobal P : 2 ;
on T echo $(P) ;
2529Fix "on target" variables during header scan, from Matt Armstrong.

Setting target-specific variables while under the influence of
the target's target-specific variables caused the _global_ values
to be modified.  This happened both during header file scanning
and with the "on target statement" syntax.

The manifestation of this was if a file #included itself, HdrRule
would accidentally set HDRRULE/HDRSCAN globally, and then all
files (executables, etc) would get scanned for includes.

While this borrows from Matt's fix, it is a slightly different
implementation.

User visible fix documented in RELNOTES.

=== computer:1666: Change 39095 by seiwald@play-seiwald on 2002/12/17 14:00:58
Status
Closed
Project
jam
Severity
C
Reported By
Miklos Fazekas
Reported Date
Modified By
Lester Cheung
Modified Date
Owned By
miklos_fazekas
Dev Notes
Fixed by change 2529