boehm-gc: revert all CACAO-specific modifications; this is now an exact copy of the...

[cacao.git] / src / mm / boehm-gc / doc / README

diff --git a/src/mm/boehm-gc/doc/README b/src/mm/boehm-gc/doc/README
index d9d49e827f4b8ba64d63d0174f7e50be42307d26..36a926a475f911417572973367c8b17fd132314b 100644 (file)
--- a/src/mm/boehm-gc/doc/README
+++ b/src/mm/boehm-gc/doc/README
@@ -28,10 +28,15 @@ modified is included with the above copyright notice.
 A few of the files needed to use the GNU-style build procedure come with
 slightly different licenses, though they are all similar in spirit.  A few
 are GPL'ed, but with an exception that should cover all uses in the
-collector.  (If you are concerned about such things, I recommend you look
+collector. (If you are concerned about such things, I recommend you look
 at the notice in config.guess or ltmain.sh.)
 
-This is version 7.1 of a conservative garbage collector for C and C++.
+The atomic_ops library contains some code that is covered by the GNU General
+Public License, but is not needed by, nor linked into the collector library.
+It is included here only becuase the atomic_ops distribution is, for
+simplicity, included in its entirety.
+
+This is version 7.2alpha3 of a conservative garbage collector for C and C++.
 
 You might find a more recent version of this at
 
@@ -202,21 +207,24 @@ simplest case), or with a classic makefile by itself (type
 On other platforms, typically only the latter option is available, though
 with a different supplied Makefile.)
 
-  Typing "make test" nstead of "make" will automatically build the collector
-and then run setjmp_test and gctest. Setjmp_test will give you information
-about configuring the collector, which is useful primarily if you have
-a machine that's not already supported.  Gctest is a somewhat superficial
-test of collector functionality.  Failure is indicated by a core dump or
-a message to the effect that the collector is broken.  Gctest takes about 
-a second to two to run on reasonable 2007 vintage desktops.
-It may use up to about 30MB of memory.  (The
-multi-threaded version will use more.  64-bit versions may use more.)
-"Make test" will also, as its last step, attempt to build and test the
-"cord" string library.)
-
-  The Makefile will generate a library gc.a which you should link against.
-Typing "make cords" will add the cord library to gc.a.
-Note that this requires an ANSI C compiler.
+  For the Makefile.direct-based process, typing "make test" instead of "make"
+will automatically build the collector and then run setjmp_test and gctest.
+Setjmp_test will give you information about configuring the collector, which is
+useful primarily if you have a machine that's not already supported.  Gctest is
+a somewhat superficial test of collector functionality.  Failure is indicated
+by a core dump or a message to the effect that the collector is broken.  Gctest
+takes about a second to two to run on reasonable 2007 vintage desktops.  It may
+use up to about 30MB of memory.  (The multi-threaded version will use more.
+64-bit versions may use more.) "Make test" will also, as its last step, attempt
+to build and test the "cord" string library.)
+
+  Makefile.direct will generate a library gc.a which you should link against.
+Typing "make cords" will add the cord library to gc.a.  
+
+  The GNU style build process understands the usual targets.  "Make check"
+runs a number of tests.  "Make install" installs at least libgc, and libcord.
+Try "./configure --help" to see the configuration options.  It is currently
+not possible to exercise all combinations of build options this way.
 
   It is suggested that if you need to replace a piece of the collector
 (e.g. GC_mark_rts.c) you simply list your version ahead of gc.a on the