#recursiveontarget fixed by change 2529 on 2002/12/19 by miklos_fazekas@mfazekasgraphisoft (closed)
# 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:	new

Status:	closed

Project:	jam

Severity:	C

ReportedBy:	miklos_fazekas

ReportedDate:	2002/12/18 07:11:56

ModifiedBy:	shawn_hladky

ModifiedDate:	2008/04/13 13:00:54

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