Home My Page Projects Code Snippets Project Openings SML/NJ
Summary Activity Forums Tracker Lists Tasks Docs Surveys News SCM Files

SCM Repository

[smlnj] Diff of /sml/trunk/src/system/README
ViewVC logotype

Diff of /sml/trunk/src/system/README

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

sml/branches/SMLNJ/src/system/README revision 429, Wed Sep 8 09:47:00 1999 UTC sml/trunk/src/system/README revision 632, Sat Apr 29 15:50:42 2000 UTC
# Line 1  Line 1 
1  !!! ATTENTION !!!  Compiler Hacker's Guide to the new CM...
2  As an SML/NJ compiler developer, please read this document carefully.  ========================================
3  The new CM has a lot of good things to offer, but you must be aware  
4  of the many changes that it incurs to the process of compiling the  Last change: 3/2000
 SML/NJ compiler.  
                         Matthias Blume (July 1999)  
 -------------------------------------------------------------------------  
5    
6  * Libraries  * Libraries
7  -----------  -----------
# Line 22  Line 19 
19  the compiler ("*" means that I consider the library potentially useful  the compiler ("*" means that I consider the library potentially useful
20  in its own right):  in its own right):
21    
22          * basis.cm      - The SML'97 basis library    * basis.cm                            SML'97 Basis Library (pre-loaded)
23          - cm-hook.cm    - an internal library for organizational purposes    * smlnj-lib.cm                        SML/NJ Utility Library
24          - cm-lib.cm     - the library that implements CM's functionality    * html-lib.cm                         SML/NJ HTML Library
25          * comp-lib.cm   - a helper library for the compiler, MLRISC, and CM    * pp-lib.cm                           SML/NJ Pretty-print Library
26          * host-cm.cm    - the library that exports the public interface to  
27                            the compilation manager (i.e., structure CM)    * ml-yacc-lib.cm                      SML/NJ ML-Yacc runtime library
28          * host-cmb.cm   - the library that exports the public interface to  
29                            the bootstrap compiler (i.e., structure CMB)    * smlnj/compiler/{alpha32,hppa,ppc,sparc,x86}.cm
30          - host-compiler-0.cm                                          cross-compiler libraries, exporting
31                          - an internal library for organizational purposes                                          structure <Arch>Compiler
32          * host-compiler.cm    * smlnj/compiler/current.cm           structure Compiler (current arch)
33                          - the library that exports the public interface to    * smlnj/compiler/all.cm               all cross-compilers and all cross-CMBs
34                            the visible compiler (i.e., structure Compiler)  
35          - intsys.cm     - an internal library for organizational purposes    * smlnj/cm/minimal.cm                 minimal CM (pre-loaded)
36                            (In fact, its the "root" of the main hierarchy.)    * smlnj/cm/full.cm                    full structure CM (see manual)
37          * ml-yacc-lib.cm - needs no further comment    * smlnj/cm/tools.cm                   CM tools library
38          * smlnj-lib.cm  - needs no further comment  
39          * target-compilers.cm    * smlnj/cmb/{alpha32,hppa,ppc,sparc,x86}-unix.cm
40                          - library exporting target-specific versions of                                          cross-bootstrap-compilers for Unix
41                            structure Compiler and of structure CMB                                          (structure <Arch>UnixCMB)
42                            (The existence of this library is the moral    * smlnj/cmb/ppc-macos.cm              ...for Mac (structure PPCMacosCMB)
43                             equivalent of "CMB.retarget" in the old CM.)    * smlnj/cmb/x86-win32.cm              ...for Windoze (structure X86Win32CMB)
44          * viscomp-lib.cm - library that implements the compiler    * smlnj/cmb/current.cm                structure CMB (current arch/os)
45                            (At the moment, its interface is rather thin.  We  
46                             should think about how to structure the interface    * smlnj/compiler.cm                   abbrev. for smlnj/compiler/current.cm
47                             in such a way that it becomes a useful equivalent    * smlnj/cm.cm                         abbrev. for smlnj/cm/full.cm
48                             to the old "full" compiler.)    * smlnj/cmb.cm                        abbrev. for smlnj/cmb/current.cm
49    
50      * comp-lib.cm                         Utility library for compiler
51    
52      - smlnj/viscomp/core.cm               Compiler core functionality
53      - smlnj/viscomp/{alpha32,hppa,ppc,sparc,x86}.cm
54                                            Machine-specific parts of compiler
55    
56      - smlnj/internal/{intsys,cm-lib,cm-hook,host-compiler-0}.cm
57                                            Glue that holds the interactive system
58                                            together
59    
60      * MLRISC/{MLRISC,Control,Lib,ALPHA,HPPA,PPC,SPARC,IA32}.cm
61                                            Various MLRISC bits
62    
63      * {mlyacc,mllex,mlburg}-tool.cm       CM plug-in libraries for common tools
64      * {grm,lex,burg}-ext.cm               CM plug-in libraries for common file
65                                            extensions
66    
67  * Before you can use the bootstrap compiler (CMB)...  * Before you can use the bootstrap compiler (CMB)...
68  ----------------------------------------------------  ----------------------------------------------------
69    
70  To be able to use CMB at all, you must first say  To be able to use CMB at all, you must first say
71    
72          CM.autoload "host-cmb.cm";          CM.autoload "smlnj/cmb.cm";
   
 after you start sml.  
   
 * Compiling the compiler -- a two-step procedure  
 ------------------------------------------------  
   
 Until now (with the old CM), once we managed to run CMB.make() to  
 completion we had a directory full of binfiles that were ready to be  
 used by the boot procedure.  This is no longer the case.  
   
 The boot procedure now wants to use stable libraries (except for the  
 part that makes up the pervasive environment).  Having stable  
 libraries around during development of these very libraries would be a  
 bit annoying because if CM sees a stable library it will no longer  
 bother to check the corresponding source files -- even if they have  
 changed.  Therefore, libraries are not stabilized until you think you  
 are ready for that.  Thus, you should run:  
   
         CMB.make ();  
   
 until you no longer get compile errors.  CMB.make will return true in  
 this case.  Then you say:  
   
         CMB.deliver ();  
   
 This command creates a second directory parallel to the "bin"  
 directory -- the "boot" directory.  It will hold everything necessary  
 to bootstrap a new heap image.  You will probably find that  
 CMB.deliver() compiles a number of additional files even though  
 CMB.make completed successfully.  This is because CMB.make compiles  
 just those modules that will actually go into the heap image, but  
 CMB.deliver must also build the remaining files -- files that are part  
 of libraries to be stabilized but which are not used by the compiler.  
   
 After you have made the boot directory, if you want to continue  
 developing the compiler (i.e., make changes to some sources,  
 recompile, etc.), you must first get rid of that boot directory.  
 Running the "makeml" script (see below) will automatically remove the  
 boot directory.  
   
 The names of "bin" and "boot" directories are  
73    
74          <prefix>.bin.<arch>-<os>  after you start sml.  Alternatively -- and perhaps more conveniently --
75    you can provide "smlnj/cmb.cm" as a command-line argument to sml:
76    
77  and        $ sml smlnj/cmb.cm
   
         <prefix>.boot.<arch>-<os>  
78    
79  respectively, with "comp" being the default for <prefix>.  To change  * Compiling the compiler
80  the prefix, use CMB.make' and CMB.deliver' with the new prefix  ------------------------
81  provided as the optional string argument to these functions.  
82    We are now back to the old scheme where a call to CMB.make() suffices to
83    build a bootable set of files (libraries in our case).  CMB.make maintains
84    two parallel hierarchies of derived files:
85    
86      1. the binfile hierarchy ("binfiles"), containing compiled objects for
87         each individual ML source file; this hierarchy is rooted at
88          <prefix>.bin.<arch>-<opsys>
89      2. the stable library hierarchy ("boot files"), containing library files
90         for each library that participates in building SML/NJ; this hierarchy
91         is rooted at
92          <prefix>.boot.<arch>-<opsys>
93    
94    The default for <prefix> is "sml".  It can be changed by using
95    CMB.make' with the new <prefix> as the optional string argument.
96    
97    CMB.make uses bootfiles after it has verified that they are consistent
98    with their corresponding binfiles.  Bootfiles do not need to be
99    deleted in order for CMB.make to work correctly.
100    
101    To bootstrap a new system (using the runtime system boot loader), the
102    bootfiles _must_ be present, the binfiles need not be present (but
103    their presence does not hurt either).
104    
105    You can reduce the number of extra files compiled and stabilized
106    during CMB.make at the expense of not building any cross-compilers.
107    For that, say
108            #set (CMB.symval "LIGHT") (SOME 1);
109    before running CMB.make.
110    
111  * Making the heap image  * Making the heap image
112  -----------------------  -----------------------
113    
114  The heap image is made by running the "makeml" script that you find  The heap image is made by running the "makeml" script that you find
115  here in this directory.  By default it will try to refer to the  here in this directory.  By default it will try to refer to the
116  comp.boot.<arch>-<os> directory.  You can change this using the -boot  sml.boot.<arch>-<os> directory.  You can change this using the -boot
117  argument (which takes the full name of the boot directory to be used).  argument (which takes the full name of the boot directory to be used).
118    
119  The "feel" of using makeml should be mostly as it used to.  However,  The "feel" of using makeml should be mostly as it used to.  However,
120  internally, there are some changes that you should be aware of:  internally, there are some changes that you should be aware of:
121    
122  1. The script will make a heap image and also move its associated  1. The script will make a heap image and build a separate library directory
123     libraries into a separate directory.     that contains links to the library files in the bootfile directory.
124    
125  2. There is no "-full" option anymore.  This functionality should  2. There is no "-full" option anymore.  This functionality should
126     eventually be provided by a library with a sufficiently rich export     eventually be provided by a library with a sufficiently rich export
# Line 132  Line 132 
132     option to actually make the image.  The argument to "-rebuild"     option to actually make the image.  The argument to "-rebuild"
133     is the <prefix> for the new bin and boot directories (see above).     is the <prefix> for the new bin and boot directories (see above).
134    
135  4. Unless you use "-rebuild", makeml will delete the boot directory  Makeml will not destroy the bootfile directory.
    (thus readying you for further "CMB.make();" runs).  
136    
137  * Testing a newly generated heap image  * Testing a newly generated heap image
138  --------------------------------------  --------------------------------------
# Line 141  Line 140 
140  If you use a new heap image by saying "sml @SMLload=..." then things  If you use a new heap image by saying "sml @SMLload=..." then things
141  will not go as you may expect because along with the new heap image  will not go as you may expect because along with the new heap image
142  should go those new stable libraries, but unless you do something  should go those new stable libraries, but unless you do something
143  about it, the new CM will look for its stable libraries in places  about it, the newly booted system will look for its stable libraries
144  where you stored your _old_ stable libraries.  in places where you stored your _old_ stable libraries.
145    
146  After you have made the new heap image, the new libraries are in a  After you have made the new heap image, the new libraries are in a
147  separate directory whose name is derived from the name of the heap  separate directory whose name is derived from the name of the heap
148  image.  The "testml" script that you also find here will run the heap  image.  (Actually, only the directory hierachy is separate, the
149  image and instruct it to look for its libraries in that new library  library files themselves are hard links.)  The "testml" script that you
150  directory.  also find here will run the heap image and instruct it to look for its
151  "testml" takes the name of the heap image as its single argument.  It  libraries in that new library directory.
152  expects the library directory to be the one that makeml builds.  
153    "testml" takes the <prefix> of the heap image as its first
154    argument. All other arguments are passed verbatim to the ML process.
155    
156    The <prefix> is the same as the one used when you did "makeml".  If
157    you run "testml" without arguments, <prefix> defaults to "sml".
158    Thus, if you just said "makeml" without argument you can also say
159    "testml" without argument.  (Note that you _must_ supply the <prefix>
160    argument if you intend to pass any additional arguments.)
161    
162  * Installing a heap image for more permanent use  * Installing a heap image for more permanent use
163  ------------------------------------------------  ------------------------------------------------
164    
165  Since you have been using the new CM already, it can be assumed that  You can "install" a newly generated heap image by replacing the old
166  you have already set up a correct pathname configuration.  (For more  image with the new one _AND AT THE SAME TIME_ replacing the old stable
167  information on pathname configurations, see below.)  With a correct  libaries with the new ones.  To do this, run the "installml" script.
168  pathname configuration in place, you can "install" a newly generated  
169  heap image by replacing the old image with the new one _AND AT THE  Like "testml", "installml" also expects the <prefix> as its first
170  SAME TIME_ replacing the old stable libaries with the new ones.  argument.  <prefix> defaults to "sml" if no argument is specified.
171    
172    "installml" patches the ../../lib/pathconfig file to reflect any
173    changes or additions to the path name mapping.
174    
175    Thus, after a successful CMB.make, you should say
176    
177            ./makeml
178    
179    to make the new heap image + libraries, then
180    
181            ./testml
182    
183    to make sure everything works, and finally
184    
185            ./installml
186    
187    to replace your existing compiler with the one you just built and tested.
188    
189  * Cross-compiling  * Cross-compiling
190  -----------------  -----------------
191    
192  All cross-compilers live in the "target-compilers.cm" library.  You  All cross-compilers live in the "smlnj/compiler/all.cm" library.  You
193  must first say  must first say
194    
195          CM.autoload "target-compilers.cm";          CM.autoload "smlnj/compiler/all.cm";
196    
197  before you can access them.  (This step corresponds to the old  before you can access them.  (This step corresponds to the old
198  CMB.retarget call.)  After that, _all_ cross-compilers are available  CMB.retarget call.)  After that, _all_ cross-compilers are available
# Line 194  Line 218 
218  (PPCMacOSCMB is not very useful at the moment because there is no  (PPCMacOSCMB is not very useful at the moment because there is no
219  implementation of the basis library for the MacOS.)  implementation of the basis library for the MacOS.)
220    
221    Alternatively, you can select just the one single structure that you
222    are interested in by auto-loading smlnj/compiler/<arch>.cm or
223    smlnj/cmb/<arch>-<os>.cm.
224    <arch> currently ranges over "alpha32", "hppa", "ppc", "sparc", and "x86.
225    <os> can be either "unix" or "macos" or "win32".
226    (Obviously, not all combinations are valid.)
227    
228    Again, as with smlnj/cmb.cm, you can specify the .cm file as an
229    argument to the sml command:
230    
231        $ sml smlnj/compiler/all.cm
232    
233    or
234    
235        $ sml smlnj/cmb/alpha32-unix.cm
236    
237  * Path configuration  * Path configuration
238  --------------------  --------------------
239    
# Line 218  Line 258 
258  in the path can upset the program that hopes to find something under  in the path can upset the program that hopes to find something under
259  the same name later on the path.  Even when ignoring security-issues  the same name later on the path.  Even when ignoring security-issues
260  like trojan horses and such, this definitely opens the door for  like trojan horses and such, this definitely opens the door for
261  various unpleasant surprises.  (Who has not ever named a test version  various unpleasant surprises.  (Who has never named a test version
262  of a program "test" an found that it acts strangely only to discover  of a program "test" an found that it acts strangely only to discover
263  later that /bin/test was run instead?)  later that /bin/test was run instead?)
264    
# Line 249  Line 289 
289    
290  During compilation of the compiler, CMB uses a path configuration that  During compilation of the compiler, CMB uses a path configuration that
291  is read from the file "pathconfig" located here in this directory.  is read from the file "pathconfig" located here in this directory.
 Warning: The names in that pathconfig file are relative pathnames and  
 will work only if you are in this directory.  (This will typically be  
 the case since you are compiling the compiler. Normally, however, path  
 configurations should map anchors to absolute pathnames.)  
292    
293  At bootstrap time, the same anchors are mapped to the corresponding  At bootstrap time, the same anchors are mapped to the corresponding
294  sub-directory of the "boot" directory: basis.cm is mapped to  sub-directory of the "boot" directory: basis.cm is mapped to
295  comp.boot.<arch>-<os>/basis.cm -- which means that CM will look for a  sml.boot.<arch>-<os>/basis.cm -- which means that CM will look for a
296  library named comp.boot.<arch>-<os>/basis.cm/basis.cm -- and so forth.  library named sml.boot.<arch>-<os>/basis.cm/basis.cm -- and so forth.
297    
298  By the way, you will perhaps notice that there is no file  By the way, you will perhaps notice that there is no file
299          comp.boot.<arch>-<os>/basis.cm/basis.cm          sml.boot.<arch>-<os>/basis.cm/basis.cm
300  but there _is_ the corresponding stable archive  but there _is_ the corresponding stable archive
301          comp.boot.<arch>-<os>/basis.cm/CM/<arch>-<os>/basis.cm          sml.boot.<arch>-<os>/basis.cm/CM/<arch>-<os>/basis.cm
302  CM always looks for stable archives first.  CM always looks for stable archives first.
303    
304  This mapping (from anchors to names in the boot directory) is the one  This mapping (from anchors to names in the boot directory) is the one
# Line 294  Line 330 
330    
331  For example, I always keep my "good" libraries in `pwd`/../../lib --  For example, I always keep my "good" libraries in `pwd`/../../lib --
332  where both the main "install" script and the "installml" script (see  where both the main "install" script and the "installml" script (see
333  below) also put them -- so I don't have to do anything special about  above) also put them -- so I don't have to do anything special about
334  my pathconfig file.  my pathconfig file.
335    
336  Once I have new heap image and libraries working, I replace the old  Once I have new heap image and libraries working, I replace the old
# Line 302  Line 338 
338    
339    mv <image>.<arch>-<osvariant> ../../bin/.heap/sml.<arch>-<osvariant>    mv <image>.<arch>-<osvariant> ../../bin/.heap/sml.<arch>-<osvariant>
340    
341  and then:  After this you must also move all libraries from <image>.libs/* to their
342    corresponding position in ../../lib.
   rm -r ../../lib/*.cm  
   mv <image>.libs/*.cm ../../lib  
343    
344  For convenience, there is a script called "installml" that automates  Since this is cumbersome to do by hand, there is a script called
345  this task.  Using the script has the added advantage that it will not  "installml" that automates this task.  Using the script has the added
346  clobber libraries that belong to other than the current architecture.  advantage that it will not clobber libraries that belong to other than
347  (The rather heavy-handed "rm/mv" approach above will delete all stable  the current architecture.  (A rather heavy-handed "rm/mv" approach
348  libraries for all architectures.)  will delete all stable libraries for all architectures.)
349    "installml" also patches the ../../lib/pathconfig file as necessary.
350    
351  Of course, you can organize things differently for yourself -- the  Of course, you can organize things differently for yourself -- the
352  path configuration mechanism should be sufficiently flexible.  path configuration mechanism should be sufficiently flexible.
# Line 347  Line 382 
382  library, n for n sub-groups), there will be just one file representing  library, n for n sub-groups), there will be just one file representing
383  the one stable archive (per architecture/os) for the whole thing.  For  the one stable archive (per architecture/os) for the whole thing.  For
384  example, I structured the standard basis into one library with two  example, I structured the standard basis into one library with two
385  sub-groups, but once you compile it (CMB.deliver) there is only one  sub-groups, but once you compile it (CMB.make) there is only one
386  stable file that represents the whole basis library.  If groups were  stable file that represents the whole basis library.  If groups were
387  allowed to appear in more than one library, then stabilization would  allowed to appear in more than one library, then stabilization would
388  duplicate the group (its code, its environment data structures, and  duplicate the group (its code, its environment data structures, and
# Line 359  Line 394 
394  keyword.  If the specification is missing (that's the "old" syntax),  keyword.  If the specification is missing (that's the "old" syntax),
395  then the the owner will be taken to be the interactive toplevel.  then the the owner will be taken to be the interactive toplevel.
396    
397  There are several examples of this throughout the system's source  * Pervasive environment, core environment, the init group "init.cmi"
 hierarchy.  One notable case is MLRISC.  It should probably be made  
 into a library of its own, but I leave this job to Lal.  At the moment  
 MLRISC.cm is a sub-group of viscomp-lib.cm.  
   
 * Pervasive environment, core environment, other "primitive" environments  
398  -------------------------------------------------------------------------  -------------------------------------------------------------------------
399    
400  Just a handful of files is compiled at the beginning in order to  CMB.make starts out by building and compiling the
401  establish a number of "primitive" environments -- including the  "init group".  This group cannot be described in the "usual" way
402  "pervasive" environment and the "core" environment.  The pervasive  because it uses "magic" in three ways:
403  environment no longer includes the entire basis library but only   - it is used to later tie in the runtime system
404  non-modular bindings (top-level bindings of variables and types).   - it exports the "core" environment
405     - it exports the "pervasive" environment
406  CM cannot automatically determine dependencies for these initial  
407  source files, but it still does use its regular cutoff recompilation  The pervasive environment no longer includes the entire basis library
408  mechanism.  Therefore, dependencies must be given explicitly.  This is  but only non-modular bindings (top-level bindings of variables and
409  done by a special description file which currently lives in  types).
410  Init/init.cmi.  See the long comment at the beginning of that file for  
411  more details.  CM cannot automatically determine dependencies (or exports) for the
412    init group source files, but it still does use its regular cutoff
413    recompilation mechanism.  Therefore, dependencies must be given
414    explicitly.  This is done by a special description file which
415    currently lives in ../system/smlnj/init/init.cmi.  See the long comment
416    at the beginning of that file for more details.
417    
418    After it is built, smlnj/init/init.cmi can be used as an "ordinary" library
419    by other libraries.  (This is done, for example, by the implementation of
420    the Basis library.)  Access to "smlnj/init/init.cmi" is protected by the
421    privilege named "primitive".  Also, note that the .cmi-file is not
422    automatically recognized as as CM description file.  Therefore, it
423    must be given an explicit member class:
424    
425         smlnj/init/init.cmi : cm
426    
427  * Autoloader  * Autoloader
428  ------------  ------------
429    
430  The new system heavily relies on the autoloader.  As a result, almost  The new system heavily relies on the autoloader.  As a result, almost
431  no static environments need to get unpickled at bootstap time.  The  no static environments need to get unpickled at bootstrap time.  The
432  construction of such environments is deferred until they become  construction of such environments is deferred until they become
433  necessary.  Because of this, I was able to reduce the size of the heap  necessary.  Thanks to this, it was possible to reduce the size of the
434  image by more than one megabyte (depending on the architecture).  The  heap image by more than one megabyte (depending on the architecture).
435  downside (although not really terribly bad) is that there is a short  The downside (although not really terribly bad) is that there is a
436  wait when you first touch an identifier that hasn't been touched  short wait when you first touch an identifier that hasn't been touched
437  before.  (I acknowledge that the notion of "short" may depend on your  before.  (I acknowledge that the notion of "short" may depend on your
438  sense of urgency. :-)  sense of urgency. :-)
439    
# Line 398  Line 442 
442  properly configured.  properly configured.
443    
444  Two libraries get pre-registered at bootstap time: the basis library  Two libraries get pre-registered at bootstap time: the basis library
445  ("basis.cm") and CM itself ("host-cm.cm").  The latter is crucial:  ("basis.cm") and CM itself ("minimal-cm.cm").  The latter is crucial:
446  without it one wouldn't be able to register any other libraries  without it one wouldn't be able to register any other libraries
447  via CM.autoload.  The registration of basis.cm is a mere convenience.  via CM.autoload.  The registration of basis.cm is a mere convenience.
448    
# Line 406  Line 450 
450  which can easily be made accessible via CM.autoload (or, non-lazily,  which can easily be made accessible via CM.autoload (or, non-lazily,
451  via CM.make):  via CM.make):
452    
453          host-compiler.cm        - provides "structure Compiler"          smlnj/cm.cm             - provides the actual ("full") structure CM
454          host-cmb.cm             - provides "structure CMB"                                    as described in the CM manual
455          target-compilers.cm     - provides "structure <Arch>Compiler" and          smlnj/cm/full.cm        - same as smlnj/cm.cm
456            smlnj/compiler.cm       - provides "structure Compiler"
457            smlnj/compiler/current.cm - same as smlnj/compiler.cm
458            smlnj/cmb.cm            - provides "structure CMB"
459            smlnj/cmb/current.cm    - same as smlnj/cmb.cm
460            smlnj/compiler/all.cm   - provides "structure <Arch>Compiler" and
461                                    "structure <Arch><OS>CMB" for various                                    "structure <Arch><OS>CMB" for various
462                                    values of <Arch> and <OS>                                    values of <Arch> and <OS>
463          smlnj-lib.cm            - the SML/NJ library          smlnj-lib.cm            - the SML/NJ library
# Line 453  Line 502 
502          defined(<namespace> <name>)          defined(<namespace> <name>)
503      is true if any of the included members preceeding this clause exports      is true if any of the included members preceeding this clause exports
504      a symbol "<namespace> <name>".      a symbol "<namespace> <name>".
505    - Within the "exports" section of the description (i.e., before "is):    - Within the "exports" section of the description (i.e., before "is"):
506      The same expression is true if _any_ of the members exports the      The same expression is true if _any_ of the members exports the
507      named symbol.      named symbol.
508      (It would be more logical if the exports section would follow the      (It would be more logical if the exports section would follow the
# Line 515  Line 564 
564  without having to move large source trees at the same time. (See my  without having to move large source trees at the same time. (See my
565  new build/install.sh script for examples of that.)  new build/install.sh script for examples of that.)
566    
567    It is possible to simulate aliases (in a way that is safer than the
568    original alias mechanism).  For example, the root.cm file (which is the
569    root of the whole system as far as CMB.make is concerned) acts as an
570    alias for smlnj/internal/intsys.cm.  In this case, root.cm is a group
571    to avoid having a (trivial) stable library file built for it.
572    
573    A library can act as an "alias" for another library if it has a
574    verbatim copy of the export list and mentions the other library as its
575    only member.  Examples for this are smlnj/cm.cm (for smlnj/cm/full.cm),
576    smlnj/compiler.cm (for smlnj/compiler/current.cm), etc.
577    
578  * Don't use relative or absolute pathnames to refer to libraries  * Don't use relative or absolute pathnames to refer to libraries
579  ----------------------------------------------------------------  ----------------------------------------------------------------
580    
581  Don't use relative or absolute pathnames to refer to libraries.  If  Don't use relative or absolute pathnames to refer to libraries.  If
582  you do it anyway, you'll get an appropriate warning at the time when  you do it anyway, you'll get an appropriate warning at the time when
583  you do CMB.deliver().  If you use relative or absolute pathnames to  you do CMB.make().  If you use relative or absolute pathnames to
584  refer to library B from library A, you will be committed to keeping B  refer to library B from library A, you will be committed to keeping B
585  in the same relative (to A) or absolute location.  This, clearly,  in the same relative (to A) or absolute location.  This, clearly,
586  would be undesirable.  would be undesirable.

Legend:
Removed from v.429  
changed lines
  Added in v.632

root@smlnj-gforge.cs.uchicago.edu
ViewVC Help
Powered by ViewVC 1.0.0