| # | Change | User | Description | Committed | |
|---|---|---|---|---|---|
| #2 | 4332 | Chris Comparini | Re-branched, this time getting everyone's versions of jam. | ||
| #1 | 4329 | Chris Comparini | Initial setup as per public depot instructions. | ||
| //guest/perforce_software/jam/src/rules.c | |||||
| #9 | 2614 | rmg |
Fix to includes of includes not being considered, broken by 2499. Details taken from email to jamming: The challenge is to make included includes appear as direct includes, so that they get considered. This used to work by recursion, because each TARGET node computed the summary of its includes -- the hfate and htime -- along with the summary of its dependents -- the fate and time. Alas, that previous arrangement confused make1() into treating headers as direct dependencies during the build phase. A.o | A.c -- A.h (Read depends down, includes across) (Failed build of A.h aborts build of A.c) The fix to the confused make1() problem was to consolidate the special handling of includes by having make0() tack onto a target's list of dependendies any of the target's dependents' includes. Unfortunately, this fix did not recurse: if the target's dependents' includes included other files, those files were not added to the target's dependencies. A.o | A.c -- A.h -- B.h -- C.h is rewritten to: A.o | \ A.c A.h -- B.h -- C.h (A.o depends on A.h, but not B.h or C.h. This is the current, broken state of jam 2.5rc1.) Matt's bugfix added some recursion at this point, by transitively appending includes' includes onto the includes chain. But, as he found out (and I did before), this can slow make0() down considerably, as typically header files all include each other and you wind up with lots of really long chains. A.o | A.c -- A.h -- B.h -- C.h is rewritten to: A.o | A.c -- A.h -- B.h -- C.h - B.h - C.h - C.h (Matt's fix: if the .h files include each other, the includes chains get very long.) The final(?) fix I have is relatively simple, but is an extra step: to have make0() replace a target's includes chain with a single pseudo-target whose dependencies are the original target's includes. That pseudo-target gets passed to make0(), which then recursively consolidates its fate and time. This then makes a target's includes fate and time available in a single target hanging off the original target. A.o | A.c -- A.h -- B.h -- C.h is rewritten to: A.o | \ A.c A.c-includes | \ A.h A.h-includes | \ B.h B.h-includes | C.h (New pseudo-target xxx-includes recursively consolidates fate and time of all included targets.) While this new scheme does add a node for every include file, it is linear, rather than exponential, and the time is pretty much neglible. User-visible bugfix not documented, because there is no place in RELNOTES for release-candidate fixes. Bumped patchlevel to 2.5rc2. |
||
| #8 | 2559 | rmg |
Fix 'var on target ?= value' so that var is only set if it did not have a target-specific value. Previously, it would just overwrite the var's value. Bug fix documented in RELNOTES. === computer:1666: Change 39566 by seiwald@play-seiwald on 2002/12/27 14:44:01 |
||
| #7 | 2529 | rmg |
Fix "on target" variables during header scan, from Matt Armstrong. Setting target-specific variables while under the influence of the target's target-specific variables caused the _global_ values to be modified. This happened both during header file scanning and with the "on target statement" syntax. The manifestation of this was if a file #included itself, HdrRule would accidentally set HDRRULE/HDRSCAN globally, and then all files (executables, etc) would get scanned for includes. While this borrows from Matt's fix, it is a slightly different implementation. User visible fix documented in RELNOTES. === computer:1666: Change 39095 by seiwald@play-seiwald on 2002/12/17 14:00:58 |
||
| #6 | 2499 | rmg |
Fix 'includes' support so that included files aren't treated as direct dependencies during the command execution phase. If an included file failed to build, make1() would bypass the including file. Now make0() appends each child's 'includes' onto its own 'depends' list, eliminating 'includes'-specific code in make0() and make1(). This not only fixes the bug, but removes some complexity as well. Bug fix documented in RELNOTES. === computer:1666: Change 38399 by seiwald@play-seiwald on 2002/12/03 16:00:40 |
||
| #5 | 2493 | rmg |
Rewrite the past: update all jam's source with comments to reflect changes since about 2.3, very early 2001. Whitespace only change. === computer:1666: Change 37660 by seiwald@play-seiwald on 2002/11/06 22:41:35 Note: I regenerated jamgram.c on my linux 7.3 system prior to the submit, since patch was so unhappy trying to lay down the changes from Christopher's change. Presumably this is just due to different yacc/bison/whatever particulars on the system where Christopher made the changes originally. - rmg |
||
| #4 | 2491 | rmg |
Some consting in jam to make it more compilable by C++ compilers. No functional change. === computer:1666: Change 37433 by perforce@perforce on 2002/10/30 16:08:51 Recreational const-ing of jam, for compilers that don't allow "string" to be passed as a non-const char *. This included a few places where we were modifying what could possibly have been read-only storage, oddly enough. No functional change. === computer:1666: Change 37602 by seiwald@play-seiwald on 2002/11/04 17:25:40 |
||
| #3 | 2482 | rmg |
Jam.html partial rewrite and the support for named parameters to rules. === computer:1666: Change 34516 by seiwald@play-seiwald on 2002/06/21 23:59:12 |
||
| #2 | 486 | Perforce staff |
Jam 2.3. See RELNOTES for a list of changes from 2.2.x. Just about every source file was touched when jam got ANSI-fied. |
||
| #1 | 2 | laura | Add Jam/MR 2.2 source | ||