Refine description in README how to build from source repository
authorIvan Maidanski <ivmai@mail.ru>
Sun, 18 May 2014 07:37:01 +0000 (11:37 +0400)
committerIvan Maidanski <ivmai@mail.ru>
Sun, 18 May 2014 07:37:01 +0000 (11:37 +0400)
README.md

index 2d19c41..b2301c7 100644 (file)
--- a/README.md
+++ b/README.md
@@ -7,6 +7,7 @@ You might find a more recent version
 [here](http://www.hboehm.info/gc/), or
 [here](https://github.com/ivmai/bdwgc).
 
+
 ## Overview
 
 This is intended to be a general purpose, garbage collecting storage
@@ -148,6 +149,7 @@ ensure that any pointers stored in thread-local storage are also
 stored on the thread's stack for the duration of their lifetime.
 (This is arguably a longstanding bug, but it hasn't been fixed yet.)
 
+
 ## Installation and Portability
 
 As distributed, the collector operates silently
@@ -159,31 +161,26 @@ Things don't appear to add up for a variety of reasons, most notably
 fragmentation losses.  These are probably much more significant for the
 contrived program "test.c" than for your application.)
 
-### Building from GIT
-The process is copied from http://www.hboehm.info/gc/ .
+On most Unix-like platforms, the collector can be built either using a
+GNU autoconf-based build infrastructure (type `./configure; make` in the
+simplest case), or with a classic makefile by itself (type
+`make -f Makefile.direct`).
 
-D is the absolute path to an installation directory:
+Please note that the collector source repository does not contain configure
+and similar auto-generated files, thus the full procedure of autoconf-based
+build of `master` branch of the collector (using `master` branch of
+libatomic_ops source repository as well) could look like:
 
-    cd D
-    git clone git://github.com/ivmai/libatomic_ops.git
     git clone git://github.com/ivmai/bdwgc.git
-    ln -s  D/libatomic_ops D/bdwgc/libatomic_ops
     cd bdwgc
+    git clone git://github.com/ivmai/libatomic_ops.git
     autoreconf -vif
     automake --add-missing
     ./configure
     make
+    make check
 
-
-### Other builds
-
-On most Unix-like platforms, the collector can be built either using a
-GNU autoconf-based build infrastructure (type `configure; make` in the
-simplest case), or with a classic makefile by itself (type
-`make -f Makefile.direct`).  Here we focus on the latter option.
-On other platforms, typically only the latter option is available, though
-with a different supplied Makefile.)
-
+Below we focus on the collector build using classic makefile.
 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
@@ -252,6 +249,7 @@ or win16 is hard.
 For machines not already mentioned, or for nonstandard compilers,
 some porting suggestions are provided in doc/porting.html.
 
+
 ## The C Interface to the Allocator
 
 The following routines are intended to be directly called by the user.
@@ -365,6 +363,7 @@ accessing garbage collector routines or variables.
 There are provisions for allocation with explicit type information.
 This is rarely necessary.  Details can be found in gc_typed.h.
 
+
 ## The C++ Interface to the Allocator
 
 The Ellis-Hull C++ interface to the collector is included in
@@ -379,6 +378,7 @@ allocator declared there to construct STL data structures.  Otherwise
 subobjects of STL data structures will be allocated using a system
 allocator, and objects they refer to may be prematurely collected.
 
+
 ## Use as Leak Detector
 
 The collector may be used to track down leaks in C programs that are
@@ -405,6 +405,7 @@ leak finding mode, `GC_debug_free` actually results in reuse of the object.
 program is not designed to run meaningfully in `FIND_LEAK` mode.
 Use "make gc.a" to build the collector.
 
+
 ## Debugging Facilities
 
 The routines `GC_debug_malloc`, `GC_debug_malloc_atomic`, `GC_debug_realloc`,
@@ -454,6 +455,7 @@ of 16 bytes form the object beginning, and some translation is necessary
 when finalization routines are invoked.  For details, about what's stored
 in the header, see the definition of the type oh in debug_malloc.c)
 
+
 ## Incremental/Generational Collection
 
 The collector normally interrupts client code for the duration of
@@ -536,6 +538,7 @@ Please address bug reports [here](mailto:bdwgc@lists.opendylan.org).
 If you are contemplating a major addition, you might also send mail to ask
 whether it's already been done (or whether we tried and discarded it).
 
+
 ## Copyright & Warranty
 
  * Copyright (c) 1988, 1989 Hans-J. Boehm, Alan J. Demers