VersionMapBuilder documentation
Russ Atkinson
Filed as: [PCedar2.0]<Documentation>VersionMapBuilderDoc.tioga
© Copyright 1986, 1990, 1991 Xerox Corporation. All rights reserved.
VersionMapBuilder is a program that builds version maps from the closure of files touched by a DF file, or from a (list of) file name pattern(s). These version maps are used to make it easier to find source and symbols files.
XEROX Xerox Corporation
Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, California 94304
For Internal Xerox Use Only
PVersionMapBuilder is a program that builds PCedar version maps from the closure of files touched by a DF file, or from a (list of) file name pattern(s). There are three commands of general interest:
PGenMap (
-(
l|
d|
t)*)*
filename
... generates version maps starting with filename.df. The maps are stored to filenameSource.versionMap, filenameIntermediate.versionMap, filenameSparcExecutable.versionMap, and filenameSparcEOptxecutable.versionMap. Progress information and error messages are displayed on a viewer and also written to a log file (PVersionMapBuilder.log). The -l switch means both (a) extract the Mimosa-style version stamps (instead of just using create dates) for derived files, and (b) write the files in the 64-bit-version format. The -d switch means to allow duplicate tuples into the written files (which is pretty silly, since duplicates arise only because of inadequacies of GenerateDFClosureImpl). The -t swtich means to write progress messages into the Commander typescript, rather than create a separate typescript Viewer; when -t is given, this command can be run in a Viewers-less world.
PMergeMap (
-(
l|
d|
t)*)*
filename
... is like PGenMap, but is faster, since it trusts the information in the files filenameSource.versionMap, etc.
PGenMapFromPatterns
Root (
-(
l|
d|
t|
m|
r|
x)*)*
pattern+
... generates version maps for files matching the given patterns. The maps are stored to RootSource.versionMap, RootIntermediate.versionMap, RootSparcExecutable.versionMap, and RootSparcEOptxecutable.versionMap. Progress information and error messages are displayed on a viewer and also written to a log file (PVersionMapBuilder.log). The -m says to do a merge into existing maps. The -r says to recurse into subdirectories. The -x provides copious, obscure debugging information and is not for the faint of heart.
For those who build PCedar version maps there are two more commands:
PGenCedarMap (
-(
l|
d|
t)*)*
filename
... generates version maps starting with filename.df The maps are stored to PCedarSource.versionMap, etc. Progress information and error messages are displayed on a viewer and also written to a log file (PVersionMapBuilder.log).
PMergeCedarMap (
-(
l|
d|
t)*)*
filename
... is like PGenCedarMap, but is faster, since it trusts the information in the files PCedarSource.versionMap, etc.
For those who are curious:
ReadVersionStamp
filename...
... reads and prints the Mimosa-style version stamp from the given files.
Version maps are useful in providing a fast mapping from short names to full names and from version stamps to full names. A list of current version maps is maintained by VersionMapDefaults. The initial default version maps can be initialized from lists of files specified in the user profile, under the keys VersionMap.SourceMaps and VersionMap.SymbolsMaps.
Following is a diagram showing the relationships between various relevent data structures in DCedar and PCedar. The data structures are MobDefs.VersionStamp (MD.VS), VersionMap.MyStamp (VM.MS), VersionMap.VersionStamp (VM.VS), and TimeStamp.Stamp (TS.S). Note that in DCedar, VM.VS is declared to be equal to TS.S, while in PCedar VM.VS is declared to be equal to MD.VS. C8, C16, and C32 stand for CARD8 (or BYTE), CARD16 (or CARDINAL in DCedar), and CARD32 (or CARDINAL in DCedar or CARD in either), respectively. The boxes in the diagram represent successive 16-bit chunks of memory; the lines indicate correspondence.
The relationship between DCedar MD.VS and PCedar MD.VS is established by the MobMapper; this relationship is such that when vs[0] is interpreted as a CARD in the natural way in each system, the resulting number is the same. The relationship between TS.S and VM.MS in DCedar is established by ancient code in VersionMapImpl; this code simply LOOPHOLEs between them. Both PCedar and DCedar Mimosa compute the MD.VS for a source file by putting the create date in [0] and 0 in [1]; similarly, the native DCedar compiler computes the TS.S for a source file from the create date by adding net=host=0. Both DCedar and PCedar VersionMapImpl keep a data structure ordered by the num field of the VM.MS; it is desired that the low-order 16 bits of the time appear here to provide a good distribution.
The relationship between MD.VS and the other two in DCedar is newly invented to make things work right. Note that, between DCedar and PCedar, corresponding fields have the corresponding values. Note also that the low-order 16 bits of the time appear in the num field of the VM.MS in both D and P Cedar.
[Artwork node; type 'Artwork on' to command tool]