Upgraded to eg++ 1.1 and libstdc++2.9

Author: jgg
Date: 1998-10-20 04:33:11 GMT
Upgraded to eg++ 1.1 and libstdc++2.9

1 files changed, 79 insertions, 0 deletions

diff --git a/README.make b/README.make
new file mode 100644
index 000000000..bee2d04c3
--- /dev/null
+++ b/README.make
@@ -0,0 +1,79 @@
+The Make System
+~~~ ~~~~ ~~~~~~
+To compile this program you require GNU Make. In fact you probably need
+GNU Make 3.76.1 or newer. The makefiles contained make use of many 
+GNU Make specific features and will not run on other makes.
+
+The make system has a number of interesting properties that are not found
+in other systems such as automake or the GNU makefile standards. In
+general some semblance of expectedness is kept so as not to be too
+surprising. Basically the following will work as expected:
+
+   ./configure
+   make
+ or
+   cd build
+   ../configure
+   make
+
+There are a number of other things that are possible that may make software
+development and software packaging simpler. The first of these is the
+environment.mak file. When configure is run it creates an environment.mak
+file in the build directory. This contains -all- configurable parameters
+for all of the make files in all of the subdirectories. Changing one
+of these parameters will have an immediate effect. The use of makefile.in 
+and configure substitutions across build makefiles is not used at all.
+
+Furthermore, the make system runs with a current directory equal to the
+source directory irregardless of the destination directory. This means
+#include "" and #include <> work as epected and more importantly
+running 'make' in the source directory will work as expected. The
+environment variable or make parameter 'BUILD' sets the build directory.
+It may be an absolute path or a path relative to the top level directory.
+By default build/ will be used with a fall back to ./ This means
+you can get all the advantages of a build directory without having to
+cd into it to edit your source code!
+
+The make system also performs dependency generation on the fly as the
+compiler runs. This is extremely fast and accurate. There is however
+one failure condition that occures when a header file is erased. In
+this case you should run make clean to purge the .o and .d files to
+rebuild.
+
+The final significant deviation from normal make practicies is 
+in how the build directory is managed. It is not mearly a mirror of
+the source directory but is logically divided in the following manner
+   bin/
+     methods/
+   doc/
+     examples/
+   include/
+     apt-pkg/
+     deity/
+   obj/
+     apt-pkg/
+     deity/
+     cmndline/
+     [...]
+Only .o and .d files are placed in the obj/ subdirectory. The final compiled
+binaries are placed in bin, published headers for inter-component linking
+are placed in include/ and documentation is generated into doc/. This means
+all runnable programs are within the bin/ directory a huge benifit for
+debugging inter-program relationships. The .so files are also placed in
+bin/ for simplicity.
+
+Using the makefiles
+~~~~~ ~~~ ~~~~~~~~~
+The makefiles for the components are really simple. The complexity is hidden
+within the buildlib/ directory. Each makefile defines a set of make variables
+for the bit it is going to make then includes a makefile fragment from
+the buildlib/. This fragment generates the necessary rules based on the
+originally defined variables. This process can be repeated as many times as
+necessary for as many programs or libraries as are in the directory.
+
+Many of the make fragments have some useful properties involving sub
+directories and other interesting features. They are more completely 
+described in the fragment code in buildlib. Some tips on writing fragments
+are included in buildlib/defaults.mak
+
+Jason