/* Keep JAMVERSYM in sync with VERSION. */ /* It can be accessed as $(JAMVERSION) in the Jamfile. */ #define VERSION "2.6rc1" #define JAMVERSYM "JAMVERSION=2.6rc1"
| # | Change | User | Description | Committed | |
|---|---|---|---|---|---|
| #3 | 4623 | Chris Comparini | Bumped version to 2.6rc1. | ||
| #2 | 4398 | Chris Comparini |
Contains the results of changelists 4393 and 4394. (Generated file) |
||
| #1 | 4331 | Chris Comparini |
Branch of what I hope is _everyone's_ jam branches, if that makes sense. |
||
| //guest/perforce_software/jam/src/patchlevel.h | |||||
| #17 | 3107 | rmg | Bump the version to rc3. | ||
| #16 | 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. |
||
| #15 | 2513 | rmg |
Set the version number and patchlevel for the 2.5rc1 release. In RELNOTES, don't document the different behavior when a "return" is not the last statement executed in rule definition as a non-backward-compatible change (in the "Compatibility" section). |
||
| #14 | 2496 | rmg |
Fix SubInclude's error message so that it actually mentions the variable that is unset. Also bumped patchlevel to 2.4.2 capriciously. Change to unreleased behavior. === computer:1666: Change 38182 by seiwald@tricks-seiwald on 2002/11/25 10:47:50 |
||
| #13 | 2484 | rmg |
Rework make0() to consider headers when deciding whether to update a temporary source file. This makes it possible to have generated, temporary source files that must be regened because an included header has been updated. === computer:1666: Change 35018 by seiwald@play-seiwald on 2002/07/17 10:41:35 Followon to 35018: actually update a "needtmp" target (duh). === computer:1666: Change 35023 by seiwald@play-seiwald on 2002/07/17 11:10:16 Fix to 35018, which handled out-of-date header files built from temporary sources. Unfortunately, the change made circular header dependencies (which are legion) get reported. Now the circular dependency reporting is done in the call to make0() rather than at the beginning of make0(), and step 3b (the header recursion) simply skips that check. Change to unreleased behavior. === computer:1666: Change 36247 by seiwald@waffle-cyg-seiwald on 2002/09/16 16:15:10 |
||
| #12 | 1658 | rmg | 2.4rc2 becomes 2.4 (final). | ||
| #11 | 1617 | rmg | Branding 2.4rc2 | ||
| #10 | 1593 | rmg | Branding this "2.4rc1". | ||
| #9 | 1580 | rmg |
Changes for 2.4beta. Yes, Christopher, I brashly said "2.4-dev WAS the beta" at tea yesterday, but I've since come to my better instincts (got chicken?), so this one will say rmg $ jam -v Jam 2.4beta. OS=LINUX. Copyright 1993-2002 Christopher Seiwald. for a week or two, at least. |
||
| #8 | 1319 | rmg |
Jam 2.3 + Perforce's internal changes. This change is a drop of the Perforce internal Jam changes since the 2.3 public release. The individual changes represented herein are preserved in the //guest/richard_geiger/intjam/ branch. The intent of this drop is to provide a base, from which other contributors' Jam branches may be integrated into. It is not intended to become a packaged release in this state. We will be integrating changes from other users prior to creating the next packaged release. Please refer to the src/RELNOTES file for an overview of the changes present in this integration. - Richard Geiger Open Source Engineer at Perforce |
||
| #7 | 556 | Perforce staff |
Patch release jam 2.3.2: reverse NOCARE change. NOCARE once again applies to targets with source and/or actions, so that buildable header files get built. |
||
| #6 | 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. |
||
| #5 | 76 | Laura Wingerd |
Integrate command-block-too-long fix, plus minor doc updates. Jam/MR release level is now 2.2.5. (change 72, change 73, change 74, change 75) |
||
| #4 | 5 | Perforce maintenance | Jam/MR 2.2.4 (HDRPATTERN, JAMUNAME, JAMSHELL, plus misc tweaks) | ||
| #3 | 4 | Perforce maintenance | Jam/MR 2.2.2 (AmigaOS support) | ||
| #2 | 3 | Perforce maintenance | Jam/MR 2.2.1 (fix for NT handle leak) | ||
| #1 | 2 | laura | Add Jam/MR 2.2 source | ||