# The form data below was edited by lester_cheung
# Perforce Public Depot Jobs
#
# Job: The job name. 'new' generates a sequenced job number.
# Status: Job status; [open/closed/suspended]. Required
# Project: The project this job is for [none/cdsp4/jam/p4hl] Optional.
# Severity: [A/B/C] (A is highest) Required.
# ReportedBy The user who created the job. Can be changed.
# ReportedDate: The date the job was created. Automatic.
# ModifiedBy: The user who last modified this job. Automatic.
# ModifiedDate: The date this job was last modified. Automatic.
# OwnedBy: The owner, responsible for doing the job. Optional.
# Description: Description of the job. Required.
# DevNotes: Developer's comments. Optional.
Job: job000038
Status: closed
Project: jam
Severity: C
ReportedBy: miklos_fazekas
ReportedDate: 2013/10/20 17:28:09
ModifiedBy: lester_cheung
ModifiedDate: 2013/10/20 17:28:36
OwnedBy: miklos_fazekas
Description:
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) ;
DevNotes:
Fixed by change 2529