13 messages in com.perforce.jamming[jamming] invoking external build pro...
FromSent OnAttachments
Alan Baljeu" <alanb@cornerstonemold.com (Alan Baljeu)01 Oct 2003 09:35 
Chris Antos01 Oct 2003 09:53 
Alan Baljeu" <alanb@cornerstonemold.com (Alan Baljeu)01 Oct 2003 11:04 
Alan Baljeu" <alanb@cornerstonemold.com (Alan Baljeu)01 Oct 2003 12:27 
Alan Baljeu" <alanb@cornerstonemold.com (Alan Baljeu)02 Oct 2003 10:00 
Alan Baljeu" <alanb@cornerstonemold.com (Alan Baljeu)02 Oct 2003 12:58 
Dag Asheim03 Oct 2003 00:34 
Mark Sheppard03 Oct 2003 04:13 
Matt Armstrong03 Oct 2003 08:35 
Alan Baljeu" <alanb@cornerstonemold.com (Alan Baljeu)06 Oct 2003 07:18 
Vladimir Prus12 Oct 2003 22:32 
Matt Armstrong13 Oct 2003 10:07 
Matt Armstrong06 Oct 2004 09:09 
Subject:[jamming] invoking external build processes
From:Matt Armstrong (ma@lickey.com)
Date:10/13/2003 10:07:04 AM
List:com.perforce.jamming

Vladimir Prus <gho@cs.msu.su> writes:

Hi Matt,

If the information to be updated is expressed completely within the jamfiles, then a built in MD5 rule might get you going. [...] That way, it'll only regenerate blddefs.h when the list of configuration values changes.

Let me make sure I understand correctly. After first build, you've got:

blddefs.h ------(depends)-----> blddesfs-<md5sum1>.h

Unitl something changes, the same dependency exists and jam thinks blddefs.h is up-to-date. When #defines change, the new dependency will be

blddefs.h ------(depends)-----> blddesfs-<md5sum2>.h

so jam will notice that blddesfs-<md5sum2>.h does not exist, and will create it and update blddefs.h, right?

Is so, then the question is: when blddesfs-<md5sum1>.h is cleaned up? Or those files are left forever?

I use the GLOB rule to find "old" versions of blddefs.h.<sum>.md5. I glob for the pattern blddefs.h.*.md5. I make the "current" blddefs.h.<sum>.md5 depend on the deletion of the out of date ones, if GLOB finds any.