# # Jamfile to build Jam (a make(1)-like program) # # There are no user-serviceable parts in this file. # # Put executables in platform-specific subdirectory. if $(VMS) { LOCATE_TARGET ?= [.binvms] ; } else if $(MAC) { LOCATE_TARGET ?= :bin.mac ; } else { LOCATE_TARGET ?= bin.$(OSFULL[1]:L) ; } # Leave generated source in current directory; it would be nice to use # these lines below to build the source into the platform-specific # directory, but getting scan.c to include the right jambase.h is # hard: with ""'s, it always gets the bootstrap version; with <>'s, # it won't find the bootstrap version. # SEARCH_SOURCE ?= $(LOCATE_TARGET) $(DOT) ; # LOCATE_SOURCE ?= $(LOCATE_TARGET) ; # # We have some different files for UNIX, VMS, and NT. # if $(NT) { code = execunix.c filent.c pathunix.c ; } else if $(OS2) { code = execunix.c fileos2.c pathunix.c ; } else if $(VMS) { code = execvms.c filevms.c pathvms.c ; } else if $(MAC) { code = execmac.c filemac.c pathmac.c ; } else { code = execunix.c fileunix.c pathunix.c ; } # We have to signal jam.h for these if $(OS) = NT { CCFLAGS += /DNT ; } # Do we know yacc? if $(YACC) { code += jamgram.y ; } else { code += jamgram.c ; } # # Build the jamgram.y from the jamgram.yy # yyacc is a slippery script that makes grammars a little # easier to read/maintain. # if $(UNIX) && $(YACC) { GenFile jamgram.y jamgramtab.h : yyacc jamgram.yy ; } # # How to build the compiled in jambase. # Main mkjambase : mkjambase.c ; # # The guts of the Jamfile: how to build Jam # Main jam : jam.c jambase.c ; LinkLibraries jam : libjam.a ; GenFile jambase.c : mkjambase Jambase ; Library libjam.a : command.c compile.c $(code) expand.c glob.c hash.c headers.c lists.c make.c make1.c newstr.c option.c parse.c regexp.c rules.c scan.c search.c timestamp.c variable.c ; if $(BINDIR) { InstallBin $(BINDIR) : jam ; } # # Distribution making from here on out. # ALLSOURCE = Build.com Build.mpw Jam.html Jambase Jambase.html Jamfile Jamfile.html Makefile Porting README RELNOTES command.c command.h compile.c compile.h execcmd.h execmac.c execunix.c execvms.c expand.c expand.h filemac.c filent.c fileos2.c filesys.h fileunix.c filevms.c glob.c hash.c hash.h headers.c headers.h jam.c jam.h jambase.c jambase.h jamgram.c jamgram.h jamgram.y jamgram.yy jamgramtab.h lists.c lists.h make.c make.h make1.c mkjambase.c newstr.c newstr.h option.c option.h parse.c parse.h patchlevel.h pathmac.c pathunix.c pathvms.c regexp.c regexp.h rules.c rules.h scan.c scan.h search.c search.h timestamp.c timestamp.h variable.c variable.h yyacc ; rule Ball { NotFile balls ; Depends balls : $(<) ; DEPENDS $(<) : $(>) ; switch $(<) { case *.tar : Tar $(<) : $(>) ; case *.shar : Shar $(<) : $(>) ; case *.zip : Zip $(<) : $(>) ; } } VERSION = jam-2.3 ; actions Tar { ln -s . $(VERSION) tar cvhf $(<) $(VERSION)/$(>) rm $(VERSION) } actions Shar { shar $(>) > $(<) } actions Zip { zip $(<) $(>) } Ball $(VERSION).shar : $(ALLSOURCE) ; Ball $(VERSION).tar : $(ALLSOURCE) ; Ball $(VERSION).zip : $(ALLSOURCE) ;
# | Change | User | Description | Committed | |
---|---|---|---|---|---|
#19 | 23298 | Nick Poole |
Updating Jam source The changes here include a simplified Windows build process: the makefile now has 2 MSVC sections, one 32-bit the other 64-bit. |
||
#18 | 9893 | brett |
On a Windows debug build the /MT flag was used in addition to the /MTd flag. Basically harmless except the compiler issued a warning for every file compiled. Removed the use of the /MT flag in the jambase arena. This allows the Jamrules to properly set this flag as required. Also when doing a Smart Heap debug build, duplicate symbols in the Smart Heap library conflicted with the standard Windows CRT library. Adding a /FORCE to the link line solves this problem. This is a very narrow case and should not effect builds without Smart Heap. Jam must be rebuilt to remove the /MT and /MTd warning. p4transfer.py: Transferred from production |
||
#17 | 9891 | brett |
Move the /MT flag for NET 2005 into jam's Jamfile and out of the Jambase file. This removes the conflict with the various TYPE=dyn, TYPE=dyng and so on, yet compiles jam as multi threaded. p4transfer.py: Transferred from production |
||
#16 | 9889 | noahf |
Jamfile ($(VMS)): Compile jamgram.c without optimization. Follow-on to change 108665. p4transfer.py: Transferred from production |
||
#15 | 9884 | tony |
jam and 2004.2 p4 client for AS/400. Built on AS/400 V5R2 with native ILE C/C++ compiler. Note, this build reports itself as P4/AS400/2004.2/76944 but this change contains porting changes that were required to make the build work so the changelist number is incorrect. This can be resolved with a clean build for 2005.1 at a later date. p4.sav and jam.sav are AS/400 "Save Files" that can be used to install the software on an AS/400 machine. The p4.sav file includes the p4.cmd and p4sync.cmd files we distributed with our older AS/400 builds. These files define a forms-type interface for supplying the parameters to the commands when you run them. Porting change only. No functional change. p4transfer.py: Transferred from production |
||
#14 | 4409 | Perforce staff |
Drop 'rc3' moniker of jam-2.5. Folded rc2 and rc3 RELNOTES into the main part of the document. Built new tar/zip balls. Only 16 months later. |
||
#13 | 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). |
||
#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 | 1571 | Perforce staff |
MINGW port by Max Blagai. Porting change documented in RELNOTES. |
||
#7 | 1355 | rmg |
Record integration of Change 281 by john_belmonte. (This was actually dropped in as part of the Jam 2.3 release; the present change serves to record the fact in the integration history, only.) |
||
#6 | 1352 | rmg |
Integrates Change 350 by grant_glouser Change 352 by grant_glouser Resolved -ay, since the changes were already present in Jam 2.3 from other sources. (This change is for the benefit of the integration history, only.) |
||
#5 | 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 |
||
#4 | 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. |
||
#3 | 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. |
||
#2 | 3 | Perforce maintenance | Jam/MR 2.2.1 (fix for NT handle leak) | ||
#1 | 2 | laura | Add Jam/MR 2.2 source |