# # There are a number of modifications made to Jam which you can either # accept or reject as you wish. # # # To turn on one of these features, either alter the default below or # set it on the Jam command line, like: # jam -sHeaderCache=1 # # CWM, 2001. AllOptions ?= "" ; DynamicCommandSize ?= "" ; ImprovedWarnings ?= True ; SerialOutput ?= "" ; SlashModifiers ?= True ; HeaderCache ?= "" ; OptionalHeaders ?= "" ; GraphDebugDump ?= True ; DebugFateChanges ?= True ; LargeBuildOutput ?= "" ; TimeStamps ?= "" ; DebugOutputMods ?= "" ; NocareNodes ?= "" ; NTBatchFileFix ?= True ; PercentDone ?= True ; ExportJobNum ?= True ; JobSlotExpansion ?= True ; # ---------------------------------------------------------------------- # A rule that checks a variable, if its set, it adds the define to the # list of defines OPT_DEFINES = ; rule config { if $($(<)) || $(AllOptions) { OPT_DEFINES += $(2) ; ECHO "Config:" $(<) is on ; $(<) = True ; # Turn on if all options is on } else { ECHO "Config:" $(<) is off ; } } if $(AllOptions) { ECHO "Config:" AllOptions is on ; } else { ECHO "Config:" AllOptions is off ; } # ---------------------------------------------------------------------- # A note on the names of the defines. # # An optional part of Jam is initially an extension. # # If an extension is accepted into to the mainline, its define is either # removed completely and the code simply placed into the mainline in a # non-conditional manner, or the EXT extension is dropped and it remains # conditional. # # For example, if the header cache code is accepted into the mainline but # as a continuing option to the build, the define would be OPT_HEADER_CACHE, # not OPT_HEADER_CACHE_EXT. # # Or something like that. Just an idea. # When creating the actions command buffer, dynamically grow the buffer # to as large as needed. Even though some shells are not able to accept # very large buffers - some OSs support amazingly large commands. Multi # mega-byte commands are ok on Solaris, HPUX, Linux, etc # # Craig McPheeters, 2001. config DynamicCommandSize : OPT_DYNAMIC_COMMAND_SIZE_EXT ; # Try to associate a filename and line number with errors and warnings # # Craig McPheeters, 2001. config ImprovedWarnings : OPT_IMPROVED_WARNINGS_EXT ; # Actions write their output into temporary files. When an action # completes, the files contents are displayed along with the associated # jam action line. This serializes the output from Jam - however it # introduces a latency in that you don't see what Jam is doing as it # works on an action, you only see the results afterwards # # Craig McPheeters, 2001. config SerialOutput : OPT_SERIAL_OUTPUT_EXT ; # Add support for the variable expansion modifiers: # $(foo:/) - which converts all \ characters to /, and # $(foo:\) - which converts all / characters to \ # These are useful mainly on NT to get the pathname syntax you want # # Craig McPheeters, 2001. config SlashModifiers : OPT_SLASH_MODIFIERS_EXT ; # The header cache is used to cache the results from the scan of each # file to find headers. Pretty much as it sounds. # # When Jam is started, the header cache is read into a hash table. Then # as each file is about to be scanned for headers, it is looked up in # the cache, and if its there and the files timestamp agrees with the # cache then the cache's results are used. This is really useful for large # builds. # # Craig McPheeters, 2001. config HeaderCache : OPT_HEADER_CACHE_EXT ; # This option allows you to ignore header dependencies when building with # Jam. If you are working with a large system, and you have modified a # low level header, you may want to delay the full build Jam would do # when it sees the dependencies that are out of date. By building with # this option, you can specify a command line argument to have include # file dependencies ignored for a build: jam -p # # Craig McPheeters, 2001. config OptionalHeaders : OPT_HEADER_OPTION_EXT ; # This option enables two new debugging levels. The first, debug level # 10 outputs a more readable form of the dependency graph. This may be # useful for people trying to understand a problem with the dependency # graph # # The second new debug level is debug level 11. This shows more # information about the fate of each target, as it is processed in make0(). # The debug level 10 extension shows you the final state of the targets. # There are times when this is insufficient to know why a target is being # updated. Debug level 11 gives a little information on why a targets fate # is changed from stable, to newer, update, missing, etc. # # Craig McPheeters, 2001. config GraphDebugDump : OPT_GRAPH_DEBUG_EXT ; # This option controls a variety of minor mods to the output of Jam which # I found more suitable when working with large systems. YMMV. # # Craig McPheeters, 2001. config LargeBuildOutput : OPT_LARGE_BUILD_EXT ; # This option places time stamps on various output messages in jam. I # found this useful to guage the performance of long builds to find # where most of the time was spent, to compare build performance between # machines, or to compare the effect on a build of any changes you are # making. # # Craig McPheeters, 2001. config TimeStamps : OPT_TIME_STAMP_OUTPUT_EXT ; # Various minor mods to the debug level 4, execcmds() level. # # Craig McPheeters, 2001. config DebugOutputMods : OPT_OUTPUT_MOD_EXT ; # This option allows you to mark an intermediate node as being # NOCARE. If an action related to the building of this node fails, # any dependencies on this NOCARE node continue anyway. This is useful # when partial results from the build are useful. # # Craig McPheeters, 2001. config NocareNodes : OPT_NOCARE_NODES_EXT ; # This option fixes a problem with the naming of batch files. # If more than one instance of Jam was run, there was a naming conflict # and the files would clobber each other # # Craig McPheeters, 2001. config BatchFileFix : OPT_FIX_BATCH_EXT ; # This displays the percentage of the build which is done, as each # rule is printed out # # Craig McPheeters, 2001. config PercentDone : OPT_PERCENT_DONE_EXT ; # Create Jam variables which shows how many jobs have been requested, # if the build is using more than one job, and a list of the job # numbers. These variables can be used in a variety of ways. # # Craig McPheeters, 2001. config ExportJobNum : OPT_EXPORT_JOBNUM_EXT ; # When building some objects, there may be conflicts between shared files # being accessed by more than one jam job. For example, when processing # yacc .y files, there are intermediate files created. If more than one # action processes yacc files at the same time, these temporary files may # collide. Most Unix shells allow you to easily incorporate a process id # into a filename, via the $$ expansion. NT's cmd.exe doesn't allow this. # This extension allows a portable method for creating temporary file # names, among other uses. Jam has a variable number of slots it can run a # command from, depending on the value of the '-j' argument. This # extension replaces a '!!' sequence in the action block with a two digit # representation of the jam slot the action is running in. There is a # maximum of 64 jobs enforced by jam, two digits is sufficient to represent # the job slot. # # The other way for jam to communicate the job slot being used by an acion # is via the '!' character in the JAMSHELL for the action. This extension # may potentially interfere with some given syntax in an action block, if # the !! character sequence is used in a different way. This hasn't been # a problem for me, and I prefer the ease of getting the job slot via this # extension. YMMV. # # Craig McPheeters, 2001. config JobSlotExpansion : OPT_JOB_SLOT_EXT ; # ---------------------------------------------------------------------- # Propogate the defines into the compiler flags if $(UNIX) { CCFLAGS += -D$(OPT_DEFINES) ; } else if $(NT) { CCFLAGS += /D$(OPT_DEFINES) ; } else { ECHO The build options are not supported on this platform. ; }
# | Change | User | Description | Committed | |
---|---|---|---|---|---|
#2 | 1229 | Craig Mcpheeters |
Modified the Jamfile to use the header cache if the feature is on A couple minor fixes, in cache_name() and hcache_init() hcache_init(). If the cache is bad, unlink the file. Avoid use of stderr, have all output go to stdout hcache(), re-organized the do/do-not use logic to avoid duplicated code |
||
#1 | 1226 | Craig Mcpheeters |
Created a branch which will be used to integrate changes from Matt Armstrong's copy of Jam. |
||
//guest/craig_mcpheeters/jam/src/Jamfile.config | |||||
#3 | 1189 | Craig Mcpheeters |
Integration of changes from my A|W work branch. Added a -d11 debug mode, which outputs information on fate changes Create jam variables to show job (-jn) information, such as the number of jobs requested, whether or not there is more than one job, and a list of the job slot numbers. These can be used in a variety of ways in supporting multi-job builds Added jobs slot expansion to the action blocks, the sequence !! is replaced by the job slot the action is running in. Modified the special shell handling to include unix. It used to be that on Unix, you could create an action block which exceeded the size that execvp() could handle (perhaps only when the DynamicCommandSize option is enabled.) On NT, all non-default shells are invoked through a intermediate file. This modification does the same for unix shells. Improved the -d+10 debug level, the dependency graph. It now shows the flags on the node as well (NOUPDATE, NOTFILE, etc.) Only issue the '...skipped' messages for nodes which would have been built |
||
#2 | 1101 | Craig Mcpheeters |
Added a percent done extension Updated the hcache code to be ansi now that Jam is |
||
#1 | 1023 | Craig Mcpheeters |
Integration from //guest/craig_mcpheeters/work/jam/src/... This return incorporates all of the Alias|Wavefront extensions to Jam, into an area which is a proper branch of the Jam mainline. An integration of these files into the Jam mainline will show all of the differences. There are several extensions to Jam in this return. Look at the new file Jamfile.config for an explanation of the extensions, and how to compile them into your own copy of Jam. If you want to build a copy of Jam with all of the extensions, do this: jam -sAllOptions=1 Read the config file for more info. The extensions range from minor output tweaks and simple fixes to more major things like a header cache, serialization of output from multiple jobs, dynamic command block sizing These are all offered without warranty, etc. |
||
//guest/craig_mcpheeters/work/jam/src/Jamfile.config | |||||
#2 | 785 | Craig Mcpheeters |
Integration from //guest/craig_mcpheeters/jam/src/... This work area now contains both the Alias|Wavefront changes, and the latest integrations from the mainline. There are some changes in this area which shouldn't be merged back into the mainline. As I merge this branch back into my jam/src/... branch, I'll leave out a few of the changes. |
||
#1 | 782 | Craig Mcpheeters |
Initial return of the Alias|Wavefront mods to jam 2.2. I made a stab at a configuration system - see the file Jamfile.config. Most of the mods are now enclosed within #ifdef blocks, which kind of pollutes the code, but may make it easier to accept or reject some of these changes. Some of these #ifdefs could disappear completely if they are accepted into the mainline This return implements the following extensions: * header cache * dynamic command block size, allowing for *large* commands * slightly improved warnings and errors * serial output from jam - nice when working with multiple jobs * an extension to variable modifiers: $(>:/) and $(>:\\) * ability to ignore header dependencies for a build (jam -p) * new debug level, -d+10, which outputs the dependency graph * added no-care support to internal nodes. if they fail, dependents are built anyway * time stamps on output * a few minor output modifications * a fix for nt batch file names conflicing when more than one jam runs at a time Each of the above can be enabled/disabled on the command line. For example, to turn on the HeaderCache code: jam -sHeaderCache=1 that is, build jam first, then use that jam to build a new one with the options you want. Some of these changes may have been made in the mainline already, my next step will be to integrate the mainline changes into these ones This return isn't yet ready for prime-time |