2 messages in com.perforce.jamming[jamming] Interested in "incremental"...| From | Sent On | Attachments |
|---|---|---|
| Hamish Macdonald | 21 Jun 2001 12:18 | |
| Badari Kakumani | 19 Dec 2002 19:36 |
| Subject: | [jamming] Interested in "incremental" builds....![]() |
|---|---|
| From: | Hamish Macdonald (ham...@tropicnetworks.com) |
| Date: | 06/21/2001 12:18:28 PM |
| List: | com.perforce.jamming |
I'm interested in enabling our developers to build incrementally upon a daily loadbuild. The idea is that only files that have changed since the daily loadbuild need to be rebuilt; only libraries whose component object files needed to be built need to be re-archived (archiving in other objects from the daily loadbuild). Only executables whose component objects or libraries need to be rebuilt would be re-linked.
I've got a mechanism working that uses GNU make and the VPATH/vpath mechanism, but I'd really like to use Jam to do my builds.
Unfortunately, Jam doesn't seem to have a mechanism that works enough like GNU makes vpath to be useful. With VPATH, GNU make will use the target found via VPATH if it is up-to-date. If it is *not* up-to-date, it throws away the VPATH-based path for the target and uses the (relative) path specified in the makefile. I can thus point VPATH/vpath at my daily loadbuild result, but have anything is rebuilt to be placed in the local build output directory. Any subsequent builds will use the local target for dependency checking also.
I thought that I could use:
LOCATE on $(target) = ... and SEARCH on $(target) = ... ...
to do this with Jam, but if $(LOCATE) is set for a target, it appears to ignore the $(SEARCH) variable. Ideally Jam would use $(SEARCH) to find an already existing file for a target, and use that to decide if it needs to build it; if it needs to build it, it would then build it in the $(LOCATE) location.
Has anyone else out there done anything like this with Jam or have any suggestions?
(I'd like to avoid copying the daily loadbuild results to the users build tree since there are 180M of object/library/debug files).
Thanks, Hamish.




