[jamming] Unnecessary recompilation - Roesler, Randy - com.perforce.jamming

21 messages in com.perforce.jamming[jamming] Unnecessary recompilation

From	Sent On	Attachments
Vladimir Prus	24 Jul 2001 08:40
Arnt Gulbrandsen	31 Jul 2001 02:23
Roesler, Randy	01 Aug 2001 12:48
Glen Darling	01 Aug 2001 22:23
Arnt Gulbrandsen	02 Aug 2001 03:17
Roger Lipscombe	02 Aug 2001 04:01
Arnt Gulbrandsen	02 Aug 2001 04:09
Arnt Gulbrandsen	02 Aug 2001 04:23
David Abrahams	02 Aug 2001 07:37
Roesler, Randy	02 Aug 2001 21:14
Roesler, Randy	02 Aug 2001 21:31
Glen Darling	02 Aug 2001 22:52
Paul Haffenden	03 Aug 2001 01:57
David Abrahams	03 Aug 2001 06:22
Arnt Gulbrandsen	03 Aug 2001 06:49
David Abrahams	03 Aug 2001 07:03
Roesler, Randy	03 Aug 2001 11:34
Roesler, Randy	03 Aug 2001 11:42
David Abrahams" <david.abrahams@rcn.com (David Abrahams)	03 Aug 2001 16:24
Glen Darling	06 Aug 2001 19:01
Arnt Gulbrandsen	07 Aug 2001 03:12

Subject:	[jamming] Unnecessary recompilation
From:	Roesler, Randy (rroe...@mdsi.bc.ca)
Date:	08/02/2001 09:31:01 PM
List:	com.perforce.jamming

Lets say that we made this change ... perhaps we break something ...

So now I

x = <funny_grist>X ; y = <other_grist>X ;

LOCATE on $x = $(cwd)/objs ; LOCATE on $y = $(cwd)/objs ;

Build $x ; Build $y ;

Sevral places in Jam I use the fact that a many jam nodes (targets) can refer to the same file at binding time.

For example

DEPENDS exports : <export>x.h ; LOCATE on <export>x.h = $(TOP)/include/cmp ; DEPENDS cmp/x.h : <export>x.h ; DEPENDS <export>x.h : x.h ; SEARCH on x.h = $(SUBDIR) ; Ln <export>x.h : x.h ;

Now, when header file scaning finds #include <cmp/x.h> jam will know that its really the same files a <export>x.h.

also

DEPENDS x.o : <grist>x.o ;

(now jam x.o builds ALL x.o's, but rarely is there more than one x in the build tree).

-----Original Message----- From: Roger Lipscombe [mailto:rlip...@riohome.com] Sent: Thursday, August 02, 2001 4:02 AM To: jamm...@perforce.com Subject: Re: [jamming] Unnecessary recompilation

That sounds like the author realized what was happening... but I still don't see any reason for it. Shouldn't the action execution code think "Oh, I've done this exact action, no need to do it again"?

Surely it's a little more complicated than that -- you could have another rule that added a "C++FLAGS on" to one of the targets, and then invoked MainFromObjects. This makes it difficult to tell whether the C++ rule is exactly the same.

I admit, however, that: a) It's not impossible to deal with this case, and... b) You'd have to be totally insane to do this without specifying a different output file/directory, to avoid confusing the two resulting .o/.obj files.

Cheers, Roger.