| 12 |
Tag: <post-commit CVS tag> |
Tag: <post-commit CVS tag> |
| 13 |
Description: |
Description: |
| 14 |
---------------------------------------------------------------------- |
---------------------------------------------------------------------- |
| 15 |
|
Name: Matthias Blume |
| 16 |
|
Date: 2000/06/16 17:30:00 JST |
| 17 |
|
Tag: blume-20000616-anchorenv |
| 18 |
|
Description: |
| 19 |
|
|
| 20 |
|
This patch implements the long anticipated (just kidding :) "anchor |
| 21 |
|
environment" mechanism. In the course of doing this, I also |
| 22 |
|
re-implemented CM's internal "SrcPath" module from scratch. The new |
| 23 |
|
one should be more robust in certain boundary cases. In any case, it |
| 24 |
|
is a lot cleaner than its predecessor (IMHO). |
| 25 |
|
|
| 26 |
|
This time, although there is yet another boot file format change, I |
| 27 |
|
kept the unpickler backward-compatible. As a result, no new bootfiles |
| 28 |
|
are necessary and bootstrapping is straightforward. (You cannot read |
| 29 |
|
new bootfiles into an old system, but the other way around is no |
| 30 |
|
problem.) |
| 31 |
|
|
| 32 |
|
Visible changes: |
| 33 |
|
|
| 34 |
|
** 1. The $<singlearc> abbreviation for $/<singlearc> for anchored |
| 35 |
|
paths has finally vanished. |
| 36 |
|
|
| 37 |
|
John had critizised this as soon as I originally proposed and |
| 38 |
|
implemented it, but at that time I did not really deeply believe |
| 39 |
|
him. :) Now I came full-circle because I need the $<singlearc> syntax |
| 40 |
|
in another place where it cannot be seen as an abbreviation for |
| 41 |
|
$/<singlearc>. To avoid the confusion, $<singlearc> now means what it |
| 42 |
|
seems to mean (i.e., it "expands" into the corresponding anchor |
| 43 |
|
value). |
| 44 |
|
|
| 45 |
|
However, when paths are used as members in CM description files, it |
| 46 |
|
continues to be true that there must be at least another arc after the |
| 47 |
|
anchor. This is now enforced separately during semantic analysis |
| 48 |
|
(i.e., form a lexical/syntactical point of view, the notation is ok.) |
| 49 |
|
|
| 50 |
|
** 2. The "cm" class now accepts an option "bind". The option's value |
| 51 |
|
is a sub-option list of precisely two items -- one labeled "anchor" |
| 52 |
|
and the other one labeled "value". As you might expect, "anchor" is |
| 53 |
|
used to specify an anchor name to be bound, and "value" specifies what |
| 54 |
|
the anchor is being bound to. |
| 55 |
|
|
| 56 |
|
The value must be a directory name and can be given in either standard |
| 57 |
|
syntax (including the possibility that it is itself an anchored path) |
| 58 |
|
or native syntax. |
| 59 |
|
|
| 60 |
|
Examples: |
| 61 |
|
|
| 62 |
|
foo.cm (bind:(anchor:bar value:$mystuff/bar)) |
| 63 |
|
lib.cm (bind:(anchor:a value:"H:\\x\\y\\z")) (* only works under windows *) |
| 64 |
|
|
| 65 |
|
and so on. |
| 66 |
|
|
| 67 |
|
The meaning of this is that the .cm-file will be processed with an |
| 68 |
|
augmented anchor environment where the given anchor(s) is/are bound to |
| 69 |
|
the given values(s). |
| 70 |
|
|
| 71 |
|
The rationale for having this feature is this: Suppose you are trying |
| 72 |
|
to use two different (already stable) libraries a.cm and b.cm (that |
| 73 |
|
you perhaps didn't write yourself). Further, suppose each of these |
| 74 |
|
two libraries internally uses its own auxiliary library $aux/lib.cm. |
| 75 |
|
Normally you would now have a problem because the anchor "lib" can not |
| 76 |
|
be bound to more than one value globally. Therefore, the project that |
| 77 |
|
uses both a.cm and b.cm must locally redirect the anchor to some other |
| 78 |
|
place: |
| 79 |
|
|
| 80 |
|
a.cm (bind:(anchor:lib value:/usr/lib/smlnj/a-stuff)) |
| 81 |
|
b.cm (bind:(anchor:lib value:/usr/lib/smlnj/b-stuff)) |
| 82 |
|
|
| 83 |
|
This hard-wires $lib/aux.cm to /usr/lib/smlnj/a-stuff/aux.cm or |
| 84 |
|
/usr/lib/smlnj/b-stuff/aux.cm, respectively. |
| 85 |
|
|
| 86 |
|
Hard-wiring path names is a bit inflexible (and CM will verbosely warn |
| 87 |
|
you when you do so at the time of CM.stabilize). Therefore, you can |
| 88 |
|
also use an anchored path as the value: |
| 89 |
|
|
| 90 |
|
a.cm (bind:(anchor:lib value:$a-lib)) |
| 91 |
|
b.cm (bind:(anchor:lib value:$b-lib)) |
| 92 |
|
|
| 93 |
|
Now you can globally configure (using the usual CM.Anchor.anchor or |
| 94 |
|
pathconfig machinery) bindings for "a-lib" and "b-lib". Since "lib" |
| 95 |
|
itself is always locally bound, setting it globally is no longer |
| 96 |
|
meaningful or necessary (but it does not hurt either). In fact, "lib" |
| 97 |
|
can still be used as a global anchor for separate purposes. As a |
| 98 |
|
matter of fact, one can locally define "lib" in terms of a global |
| 99 |
|
"lib": |
| 100 |
|
|
| 101 |
|
a.cm (bind:(anchor:lib value:$lib/a)) |
| 102 |
|
b.cm (bind:(anchor:lib value:$lib/b)) |
| 103 |
|
|
| 104 |
|
** 3: The encoding of path names has changed. This affects the way |
| 105 |
|
path names are shown in CM's progress report and also the internal |
| 106 |
|
protocol encoding used for parallel make. |
| 107 |
|
|
| 108 |
|
The encoding now uses one or more ':'-separated segments. Each |
| 109 |
|
segments corresponds to a file that has been specified relative to the |
| 110 |
|
file given by its preceding segment. The first segment is either |
| 111 |
|
relative to the CWD, absolute, or anchored. Each segment itself is |
| 112 |
|
basically a Unix pathname; all segments but the first are relative. |
| 113 |
|
|
| 114 |
|
Example: |
| 115 |
|
|
| 116 |
|
$foo/bar/baz.cm:a/b/c.sml |
| 117 |
|
|
| 118 |
|
This path denotes the file bar/a/b/c.sml relative to the directory |
| 119 |
|
denoted by anchor "foo". Notice that the encoding also includes |
| 120 |
|
baz.cm which is the .cm-file that listed a/b/c.sml. As usual, such |
| 121 |
|
paths are resolved relative to the .cm-files directory, so baz.cm must |
| 122 |
|
be ignored to get the "real" pathname. |
| 123 |
|
|
| 124 |
|
To make this fact more obvious, CM puts the names of such "virtual |
| 125 |
|
arcs" into parentheses when they appear in progress reports. (No |
| 126 |
|
parentheses will appear in the internal protocol encoding.) Thus, |
| 127 |
|
what you really see is: |
| 128 |
|
|
| 129 |
|
$foo/bar/(baz.cm):a/b/c.sml |
| 130 |
|
|
| 131 |
|
I find this notation to be much more informative than before. |
| 132 |
|
|
| 133 |
|
Another new feature of the encoding is that special characters |
| 134 |
|
including parentheses, colons, (back)slashes, and white space are |
| 135 |
|
written as \ddd (where ddd is the decimal encoding of the character). |
| 136 |
|
|
| 137 |
|
---------------------------------------------------------------------- |
| 138 |
Name: Allen Leung |
Name: Allen Leung |
| 139 |
Date: 2000/06/15 00:38:00 |
Date: 2000/06/15 00:38:00 |
| 140 |
Tag: leunga-20000615-x86-peephole |
Tag: leunga-20000615-x86-peephole |
Parent Directory
| 
Revision Log
| 
Patch
