Added some entity declarations for often used terms.

Added section 1.1 : HOWTO overview.

LDP/howto/docbook/GNU-Build-System-HOWTO/GNU-Build-System-HOWTO.xml

@@ -4,7 +4,21 @@ $Id$
 -->
 
 <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
-     "/usr/share/sgml/docbook/xml-dtd-4.1.2/docbookx.dtd">
+     "/usr/share/sgml/docbook/xml-dtd-4.1.2/docbookx.dtd" [
+
+<!ENTITY make "<command>make</command>">
+<!ENTITY autoconf "<command>autoconf</command>">
+<!ENTITY automake "<command>automake</command>">
+<!ENTITY libtool "<command>libtool</command>">
+<!ENTITY libtoolize "<command>libtoolize</command>">
+<!ENTITY configure "<command>configure</command>">
+
+<!ENTITY makefile "<filename>Makefile</filename>">
+<!ENTITY makefile_in "<filename>Makefile.in</filename>">
+<!ENTITY makefile_am "<filename>Makefile.am</filename>">
+<!ENTITY configure_in "<filename>confgure.in</filename>">
+
+]>
 
 <article>
 
@@ -51,7 +65,7 @@ $Id$
      <!-- Provide a good abstract; a couple of sentences is sufficient -->
      <abstract>
         <para>
-         This HOWTO aims to help beginning developers to leverage the power the the GNU Build System (GBS); The GBS is composed of well-known tools such as <command>make</command> and of less-used utilities such as <command>autconf, automake</command> or <command>libtool.</command>. The primary goal of the HOWTO is to ring developers up to speed with each of these tools, and, at another level to explain some of their inner workings.
+         This HOWTO aims to help beginning developers to leverage the power the the GNU Build System (GBS); The GBS is composed of well-known tools such as &make; and of less-used utilities such as &autoconf;, &automake; or &libtool;. The primary goal of the HOWTO is to ring developers up to speed with each of these tools, and, at another level to explain some of their inner workings.
         </para>
      </abstract>
 
@@ -63,9 +77,14 @@ $Id$
 <sect1 id="intro">
   <title>Introduction</title>
 
-  <para>
-   Overview of the document.
-  </para>
+    <sect2 id="overview">
+      <title>The GBS-HOWTO at a glance</title>
+      <para>The GNU Build System encompasses a vast number of components assisting the developer in every stage of the compile/configure/distribute process. Projects using the whole suite of the GBS are recognizable by the ease with which they are installed. Basically the ubiquitous "<command>./configure && make && make install</command>" triplet does the trick. This HOWTO aims to take the reader step by step through the stages turning a set of source files into a "project" conforming to this GBS mantra. To be able to follow the explanations given in this HOWTO, the reader is expected to be familiar with the basics of using a compiler to build executables from source files.</para>
+      <para>A first part of this HOWTO (<xref linkend="using"/>) will work through each of these components in turn using a toy example. This will acquaint the reader with the basic usage patterns of building &makefile;s to automate most if not all of a project's source code compilation thanks to the &make; command. This will also highlight the need to rely on other tools to ensure that compilation will perform correctly on most flavors of Unix (including Linux of course). Hence, the first step is to let Autoconf take care of platform-specific parameters by building an appropriate &configure; script by the &autoconf; command. We'll also transform our &makefile; into a &makefile_in; which abstracts away the platform related compilation issues. Though greatly automated, this step still requires some tweaking, but that's what this HOWTO's been made for after all. The final step to build a well-behaved and distributable software project is to supply &make; with a set of standard targets and to use a set of thoroughly tested recipes to build them. This is where &automake; comes into play. Starting from a high-level description of the project's components (source files, binaries to be built, documentation, additional data files) found in a &makefile_am;, &automake; is capable of generating a suitable &makefile_in;. So that's it? Now we've got our GBS compliant project architecture, isn't it? Indeed, but our toolkit would be incomplete if we omitted to mention &libtool;. This last component favours the use of program libraries (sets of related object files grouped into a single archive). These libraries can the be used by all executables of a project, and in some cases, without being copied in every single executable. Ways of building these libraries vary much from platform to platform, but luckily, &libtool; now greatly simplifies this process, lifting this burden from the programmer.</para>
+      <para>After this entry-level guided tour, a real world programming project will be subjected to the whole slew of procedures just described (<xref linkend="realworld"/>).  There's no such thing as a real world example to expose some of the hurdles that inevitably show up when things get a bit more complex.</para>
+    <para>To the survivors of the former section, we recommend the more in-depth look at the inner workings of all the GBS components provided in <xref linkend="inside"/>. Just for starters, it describes the innards of the &make; before covering a rather ill-known macro programming language, <command>m4</command> upon which several of the GBS tools are built. It then scrutinises &autoconf;, &automake; and &libtool; to explain their what's and how's.</para>
+      <para>The last section of the HOWTO covers the installation of the GBS components, either from pre-packaged files specific to Linux distributions, or from source <filename>.tar.g</filename> archives (also called <emphasis>tarballs</emphasis>).</para>
+    </sect2>
 
     <sect2 id="about">
       <title>About this HOWTO</title>
@@ -84,7 +103,7 @@ $Id$
     <!-- The LDP recommends, but doesn't require, the GFDL --> 
     <para>
      This document, the <emphasis>GNU-Build-System HOWTO</emphasis>, is
-     copyrighted (c) 2002 by <emphasis>Y Giridhar Appaji
+     copyrighted (c) 2003 by <emphasis>Y Giridhar Appaji
      Nag</emphasis> and <emphasis>Mark Hoebeke</emphasis>.  Permission
      is granted to copy, distribute and/or modify this document under
      the terms of the GNU Public License, Version 2 or any later