13 messages in com.perforce.jamming[jamming] compile.c: compile_on(): Wh...| From | Sent On | Attachments |
|---|---|---|
| Ingo Weinhold | 18 Nov 2002 07:18 | |
| Christopher Seiwald | 18 Nov 2002 12:28 | |
| Matt Armstrong | 18 Nov 2002 13:04 | |
| Craig McPheeters | 18 Nov 2002 13:09 | |
| Matt Armstrong | 18 Nov 2002 13:44 | |
| Ingo Weinhold | 18 Nov 2002 16:40 | |
| Christopher Seiwald | 20 Nov 2002 14:48 | |
| Arnt Gulbrandsen | 21 Nov 2002 01:27 | |
| Jacob Gorm Hansen | 21 Nov 2002 01:52 | |
| Ingo Weinhold | 21 Nov 2002 02:14 | |
| Christopher Seiwald | 21 Nov 2002 22:30 | |
| Robert Cowham | 22 Nov 2002 07:27 | |
| Matt Armstrong | 23 Nov 2002 20:44 |
| Subject: | [jamming] compile.c: compile_on(): Why search()? |
|---|---|
| From: | Ingo Weinhold (bone...@cs.tu-berlin.de) |
| Date: | 11/21/2002 02:14:10 AM |
| List: | com.perforce.jamming |
On Thu, 21 Nov 2002, Arnt Gulbrandsen wrote:
Christopher Seiwald writes:
One trick I did regularly back in the early days of Jam was to scope it to just certain directories: my part of the code and the directories where the Main (linking) rules were. I just had an otherwise empty directory with a Jamfile that included (via SubInclude) directly the Jamfiles of the interesting subdirectories.
That way I could go to that directory for quickie rebuilds and to the root for a full scan.
I can't see any guarantee that a rebuild in that directory will cause exactly the same actions as a rebuild in the root directory. Any difference there would be a Bad Thing. Any undetected difference would be a Very Bad Thing.
I have to agree. I actually modified my jam copy to always read the whole jamfile tree -- even when invoking it in a subdirectory -- to ensure consistency (nevertheless building only the targets in the concerned subtree and whatever they depend on). This increases the turn around times for the developers, but, after having experienced some unwanted effects, I think it's worth it.
It also seems likely to need O(>1) human actions; the quickie rebuilds would sometimes require changes to the quickie Jamfile.
I admit, it is having the developer do some of what Jam should do (figure out how extensive the code changes are), but to my mind it is no more unsettling than the developer being mindful of Jam keeping state.
IMNSHO it's philosophically worse. The developer knowing that jam keeps a file in /tmp/jam is one thing; the developer regularly spending brain cells on doing jam's work is quite another.
Exactly. What I like jam for particularly, is that the developer doesn't need to meddle with build system issues other than extending or adding a jamfile from time to time. A simple `jam [target]' does the trick for them. No need to worry about dependencies or to manually fix things occasionally.
CU, Ingo