allow vendors to install configuration files

[apt.git] / README.make

diff --git a/README.make b/README.make
index 1d87c02cb3a459bfc0dd526ffb2baa6e37a07be5..db5f36e9414c43ed009c9d6c1096025c7bb8ae69 100644 (file)
--- a/README.make
+++ b/README.make
@@ -25,23 +25,23 @@ 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
+source directory regardless of the destination directory. This means
+#include "" and #include <> work as expected 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
+By default build-arch/ then 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
+one failure condition that occurs 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 final significant deviation from normal make practices is 
+in how the build directory is managed. It is not nearly a mirror of
 the source directory but is logically divided in the following manner
    bin/
      methods/
@@ -49,16 +49,14 @@ the source directory but is logically divided in the following manner
      examples/
    include/
      apt-pkg/
-     deity/
    obj/
      apt-pkg/
-     deity/
-     cmndline/
+     cmdline/
      [...]
 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
+all runnable programs are within the bin/ directory, a huge benefit for
 debugging inter-program relationships. The .so files are also placed in
 bin/ for simplicity.
 
@@ -89,8 +87,9 @@ Autoconf
 ~~~~~~~~
 Straight out of CVS you have to initialize autoconf. This requires 
 automake (I really don't know why) and autoconf and requires doing 
-  aclocal -I buidlib
+  aclocal -I buildlib
   autoconf
+[Alternatively you can run make startup in the top level build dir]
 
 Autoconf is configured to do some basic system probes for optional and 
 required functionality and generate an environment.mak and include/config.h 
@@ -104,10 +103,10 @@ build include/ dir and perhaps writing some replacement code and
 linking it in. To the fullest extent possible the source code should conform
 to standards and not cater to broken systems.
 
-Autoconf will also wite a makefile into the top level of the build dir, 
+Autoconf will also write a makefile into the top level of the build dir, 
 this simply acts as a wrapper to the main top level make in the source tree.
 There is one big warning, you can't use both this make file and the
 ones in the top level tree. Make is not able to resolve rules that 
 go to the same file through different paths and this will confuse the
 depends mechanism. I recommend always using the makefiles in the
-source directory and exporting BUILD
+source directory and exporting BUILD.