Merged revisions 2136-2200,2202-2290,2292-2301 via svnmerge from

http://scons.tigris.org/svn/scons/branches/core

........
  r2145 | stevenknight | 2007-07-17 09:15:12 -0500 (Tue, 17 Jul 2007) | 3 lines

  Don't put null strings (from variable expansion) in a path list.
  (They get turned into the current directory on later expansion.)
........
  r2146 | stevenknight | 2007-07-17 10:47:39 -0500 (Tue, 17 Jul 2007) | 3 lines

  Add support for optional arguments on command-line long options
  by specifying nargs='?'.
........
  r2149 | stevenknight | 2007-07-17 15:22:24 -0500 (Tue, 17 Jul 2007) | 2 lines

  Remove left-over Optik mentions.
........
  r2150 | stevenknight | 2007-07-17 15:39:34 -0500 (Tue, 17 Jul 2007) | 4 lines

  Add a $SWIGPATH variable for finding SWIG dependencies, with
  $SWIGINC{PREFIX,SUFFIX} for adding them to the command line.
........
  r2154 | stevenknight | 2007-07-18 20:05:31 -0500 (Wed, 18 Jul 2007) | 2 lines

  Fix variable misspellings in the doc added for $SWIGOUTPUT.
........
  r2155 | stevenknight | 2007-07-18 20:07:28 -0500 (Wed, 18 Jul 2007) | 2 lines

  Add the Python eggs info file to the RPM packaging build.
........
  r2156 | stevenknight | 2007-07-18 20:15:08 -0500 (Wed, 18 Jul 2007) | 2 lines

  Convert documentation from DocBook SGML to XML.
........
  r2158 | stevenknight | 2007-07-19 17:16:19 -0500 (Thu, 19 Jul 2007) | 3 lines

  Conditionally add the .egg-info the RPM file list only if the distutils
  in the version of Python that rpmbuild will execute knows about them.
........
  r2161 | stevenknight | 2007-07-19 19:12:29 -0500 (Thu, 19 Jul 2007) | 5 lines

  Capture a test case (contributed by Tilo Prutz) where instantiation of
  a private class causes javac to generate an additional anonymous inner
  class file.  (No solution yet, but there's no sense throwing away the
  preparatory work.)
........
  r2162 | stevenknight | 2007-07-20 11:29:56 -0500 (Fri, 20 Jul 2007) | 3 lines

  Support passing a list of .java files as source to the Java() builder.
  (Leanid Nazdrynau)
........
  r2163 | garyo | 2007-07-20 12:00:35 -0500 (Fri, 20 Jul 2007) | 1 line

  Fixed cut-n-paste error in Touch factory method doc in users guide.
........
  r2167 | stevenknight | 2007-07-21 22:59:40 -0500 (Sat, 21 Jul 2007) | 2 lines

  Don't execute the SWIGOUTDIR test if swig isn't installed.
........
  r2168 | stevenknight | 2007-07-21 23:14:17 -0500 (Sat, 21 Jul 2007) | 2 lines

  Fix the test's ability to run under a path name containing spaces.
........
  r2171 | stevenknight | 2007-07-24 15:54:41 -0500 (Tue, 24 Jul 2007) | 2 lines

  Handle white space in key file names in the packaging build.
........
  r2172 | stevenknight | 2007-07-24 21:41:15 -0500 (Tue, 24 Jul 2007) | 2 lines

  More efficient copying of construction environments.
........
  r2173 | stevenknight | 2007-07-25 10:56:02 -0500 (Wed, 25 Jul 2007) | 2 lines

  Update the SCons build for Subversion and general clean-up.
........
  r2174 | stevenknight | 2007-07-25 11:35:16 -0500 (Wed, 25 Jul 2007) | 3 lines

  Suppress the [brackets] around a node in the --tree=prune output if
  the node is a source.
........
  r2175 | stevenknight | 2007-07-25 12:52:18 -0500 (Wed, 25 Jul 2007) | 3 lines

  Commonize the skip_test() method and make its behavior configurable
  via a TESTCOMMON_PASS_SKIPS environment variable.
........
  r2178 | stevenknight | 2007-07-25 21:43:47 -0500 (Wed, 25 Jul 2007) | 3 lines

  Add $JAVACLASSPATH and $JAVASOURCEPATH construction variables.  (Leanid
  Nazdrynau)
........
  r2182 | stevenknight | 2007-07-30 12:10:20 -0500 (Mon, 30 Jul 2007) | 3 lines

  Refactor Builder suffix-adjusting into its own method, so we can
  (potentially) re-use it for Builders with attached source Builders.
........
  r2183 | stevenknight | 2007-07-30 14:51:53 -0500 (Mon, 30 Jul 2007) | 2 lines

  More efficient source-builder suffix matching.
........
  r2184 | stevenknight | 2007-07-30 16:01:42 -0500 (Mon, 30 Jul 2007) | 4 lines

  Encapsulate initialization of the default FS object by an accessor
  function in SCons.Node.FS.  (This also gets rid of an unnecessary
  reference to SCons.Node.FS.default_fs in the LaTeX scanner.)
........
  r2193 | stevenknight | 2007-07-30 18:24:07 -0500 (Mon, 30 Jul 2007) | 3 lines

  Fix interpretation of source arguments that have no suffix when the
  called Builder has both a src_suffix and a src_builder.
........
  r2194 | stevenknight | 2007-07-31 10:25:31 -0500 (Tue, 31 Jul 2007) | 2 lines

  Increase the number of tries for random output from three to ten.
........
  r2195 | stevenknight | 2007-07-31 10:52:28 -0500 (Tue, 31 Jul 2007) | 3 lines

  Skip the test gracefully if the zipfile module can't read the file it
  just wrote (which is the case for Python 2.1 on 64-bit systems).
........
  r2196 | stevenknight | 2007-07-31 13:06:21 -0500 (Tue, 31 Jul 2007) | 2 lines

  Move the "import zipfile" so it doesn't fail on Python <= 2.0.
........
  r2197 | stevenknight | 2007-07-31 14:51:50 -0500 (Tue, 31 Jul 2007) | 3 lines

  Commonize initialization of the various Java builders so they can be
  hooked up into a multi-stage Builder chain.  (Leanid Nazdrynau)
........
  r2198 | stevenknight | 2007-07-31 16:15:18 -0500 (Tue, 31 Jul 2007) | 3 lines

  Fix use of ${TARGET.dir} and ${SOURCE.dir} expansions in $FORTRANMODDIR
  $JARCHDIR, $JARFLAGS, $LEXFLAGS, $SWIGFLAGS, $SWIGOUTDIR and $YACCFLAGS.
........
  r2199 | stevenknight | 2007-07-31 16:25:48 -0500 (Tue, 31 Jul 2007) | 2 lines

  Remove left-over Trace() call.
........
  r2202 | stevenknight | 2007-08-01 12:31:48 -0500 (Wed, 01 Aug 2007) | 3 lines

  Bail out via test.skip_test() if wix ("candle") isn't found.
  Put the main body of code flush left instead of under an if: block.
........
  r2203 | stevenknight | 2007-08-01 15:35:55 -0500 (Wed, 01 Aug 2007) | 5 lines

  Fix Tool.packaging.rpm.package() so it doesn't always overwrite
  $RPMFLAGS with -ta.
  Set --buildroot in RPM packaging tests so they don't overwrite
  each other when run simultaneously.
........
  r2204 | stevenknight | 2007-08-01 15:37:36 -0500 (Wed, 01 Aug 2007) | 2 lines

  Fix a nested scope issue with the internal build_sources() function.
........
  r2205 | stevenknight | 2007-08-01 15:46:08 -0500 (Wed, 01 Aug 2007) | 5 lines

  Normalize (X out) the CreationDate field inside embedded, compressed
  PostScript streams within the generated PDF files.  Also normalize
  preceding Length field, since compression length is affected by different
  patterns of input, including the variable CreationDate value.
........
  r2211 | stevenknight | 2007-08-02 08:52:06 -0500 (Thu, 02 Aug 2007) | 2 lines

  Add the new modules from branches/packaging to the SCons packaging build.
........
  r2212 | stevenknight | 2007-08-02 19:59:01 -0500 (Thu, 02 Aug 2007) | 2 lines

  Fix the JAVACLASSPATH test when javah isn't on the default $PATH.
........
  r2214 | stevenknight | 2007-08-03 15:05:21 -0500 (Fri, 03 Aug 2007) | 4 lines

  Hook up the Java builders into a multi-step chain underneath a Java()
  pseudo-builder (wrapper) that examines its arguments and calls the
  appropriate underlying file-or-dir builder.
........
  r2215 | stevenknight | 2007-08-03 15:49:58 -0500 (Fri, 03 Aug 2007) | 2 lines

  Fix for old Python versions:  use apply() instead of *args, **kw.
........
  r2216 | stevenknight | 2007-08-03 16:49:31 -0500 (Fri, 03 Aug 2007) | 2 lines

  Hook up the SWIG builder as a source builder for .java files.
........
  r2217 | stevenknight | 2007-08-03 17:28:19 -0500 (Fri, 03 Aug 2007) | 2 lines

  Don't use .endswith(), which didn't appear until later Python versions.
........
  r2218 | stevenknight | 2007-08-03 17:29:38 -0500 (Fri, 03 Aug 2007) | 2 lines

  Replace tabs with spaces.
........
  r2219 | stevenknight | 2007-08-04 08:06:23 -0500 (Sat, 04 Aug 2007) | 3 lines

  Initialize a loop-invariant lambda for matching .java suffixes outside
  the loop.
........
  r2220 | stevenknight | 2007-08-07 15:06:13 -0500 (Tue, 07 Aug 2007) | 2 lines

  Refactor parallel class-generation loops into one.
........
  r2221 | stevenknight | 2007-08-07 16:04:06 -0500 (Tue, 07 Aug 2007) | 5 lines

  Have the Java multi-step builder test actually check for generated files,
  and fix the generation of .java and .class file names, and interaction
  with the SWIG builder, so that the files are generated in the correct
  place.
........
  r2222 | stevenknight | 2007-08-07 16:45:05 -0500 (Tue, 07 Aug 2007) | 3 lines

  Fix dependencies on SWIG-generated .java files so they don't have to
  be built in multiple passes.
........
  r2226 | stevenknight | 2007-08-07 18:00:22 -0500 (Tue, 07 Aug 2007) | 2 lines

  Fix SWIG when used with BuildDir().
........
  r2227 | stevenknight | 2007-08-07 22:15:55 -0500 (Tue, 07 Aug 2007) | 5 lines

  User's guide updates:
  - Make the multiple files example match its text.
  - Expand a truncated sentence about being able to use Python function actions
    in the Command() Builder.
........
  r2228 | stevenknight | 2007-08-07 23:25:18 -0500 (Tue, 07 Aug 2007) | 3 lines

  Don't generate an error if a #include file matches a same-named
  directory in $CPPPATH (or $FORTRANPATH, etc.).
........
  r2229 | stevenknight | 2007-08-07 23:40:00 -0500 (Tue, 07 Aug 2007) | 2 lines

  Fix a code example.  (Gary Oberbrunner)
........
  r2230 | stevenknight | 2007-08-08 00:05:43 -0500 (Wed, 08 Aug 2007) | 3 lines

  Capture a test case to make sure AddPostAction() doesn't interfere
  with normal linking.  (Matt Doar, Gary Oberbrunner)
........
  r2233 | stevenknight | 2007-08-08 14:15:44 -0500 (Wed, 08 Aug 2007) | 2 lines

  Fix documentation typo in a construction variable cross-reference.
........
  r2234 | stevenknight | 2007-08-08 17:03:25 -0500 (Wed, 08 Aug 2007) | 2 lines

  Changes to SCons packaging to support checkpoint releases.
........
  r2235 | stevenknight | 2007-08-09 10:10:01 -0500 (Thu, 09 Aug 2007) | 2 lines

  Sidestep false negatives on heavily loaded systems.
........
  r2236 | garyo | 2007-08-09 11:16:26 -0500 (Thu, 09 Aug 2007) | 1 line

  Allow unpackaged files (e.g. *.pyo) to exist in the build dir without being packaged in the RPM.  Without this, on some systems the rpmbuild may error out.
........
  r2237 | stevenknight | 2007-08-09 11:27:56 -0500 (Thu, 09 Aug 2007) | 5 lines

  Fix test/SWIG/build-dir.py so it works on old Python versions without
  distutils.sysconfig.
  Instead of just cutting-and-pasting initialization code from other
  SWIG tests, centralize it in some new TestSCons methods.
........
  r2238 | garyo | 2007-08-09 11:30:58 -0500 (Thu, 09 Aug 2007) | 1 line

  Use docbook 4.3 instead of 4.4 for the XML doctype since some older(?) jade parsers can't handle new 4-byte Unicode chars in the 4.4 version of isogrk4.ent.
........
  r2240 | stevenknight | 2007-08-09 16:35:06 -0500 (Thu, 09 Aug 2007) | 2 lines

  User's Guide updates (post packaging changes).
........
  r2243 | stevenknight | 2007-08-10 10:31:51 -0500 (Fri, 10 Aug 2007) | 3 lines

  Fix the User's Guide build to use openjade, and to accomodate a change
  in the name of the main generated file (book1.html => index.html).
........
  r2245 | stevenknight | 2007-08-10 11:09:16 -0500 (Fri, 10 Aug 2007) | 2 lines

  Update the {CHANGES,RELEASE}.txt datestamp lines.
........
  r2253 | stevenknight | 2007-08-10 16:21:54 -0500 (Fri, 10 Aug 2007) | 2 lines

  Fix the wix Tool module's ability to handle null entries in $PATH.
........
  r2261 | stevenknight | 2007-08-11 23:08:12 -0500 (Sat, 11 Aug 2007) | 3 lines

  Remove unnecessary files (.svnt/*, .{ae,cvs}ignore, www/*) from the
  scons-src packages.
........
  r2262 | stevenknight | 2007-08-11 23:24:49 -0500 (Sat, 11 Aug 2007) | 2 lines

  Add missing __revision__ lines.
........
  r2263 | stevenknight | 2007-08-11 23:33:42 -0500 (Sat, 11 Aug 2007) | 2 lines

  Skip the test if the MANIFEST file hasn't been built.
........
  r2264 | stevenknight | 2007-08-11 23:36:30 -0500 (Sat, 11 Aug 2007) | 2 lines

  Add recent compatibility modules to the relevant exceptions lists.
........
  r2265 | stevenknight | 2007-08-11 23:39:00 -0500 (Sat, 11 Aug 2007) | 3 lines

  Update __VERSION__ strings in the QMTest/*.py modules, so that packaging
  tests (src/test_*.py) will pass after builds of checkpoint releases.
........
  r2266 | stevenknight | 2007-08-12 07:36:19 -0500 (Sun, 12 Aug 2007) | 2 lines

  Add a comment about why we construct the __VERSION__ string at run time.
........
  r2267 | stevenknight | 2007-08-12 07:42:30 -0500 (Sun, 12 Aug 2007) | 2 lines

  Avoid reading the MANIFEST file twice.  (Courtesy review by Greg Noel.)
........
  r2268 | stevenknight | 2007-08-12 08:14:53 -0500 (Sun, 12 Aug 2007) | 3 lines

  Shift Install() and InstallAs() from being documented as functions
  to being documented as Builders.
........
  r2269 | garyo | 2007-08-13 08:49:52 -0500 (Mon, 13 Aug 2007) | 1 line

  Tests: Skip some more Java tests if javac is not installed on the test machine so they don't get marked as failing.
........
  r2270 | garyo | 2007-08-13 11:09:39 -0500 (Mon, 13 Aug 2007) | 1 line

  Fixed typo in test (shows up on non-Linux platforms).
........
  r2271 | garyo | 2007-08-13 14:09:05 -0500 (Mon, 13 Aug 2007) | 4 lines

  Test portability fixes for Darwin/OSX and IRIX.
  This does not make all the tests pass on those OSes,
  but it takes care of some of the more obvious errors that
  I have time for right now.  More to come.
........
  r2272 | stevenknight | 2007-08-13 15:33:29 -0500 (Mon, 13 Aug 2007) | 2 lines

  Tab => space fix.
........
  r2273 | stevenknight | 2007-08-13 15:33:52 -0500 (Mon, 13 Aug 2007) | 2 lines

  Test for swig, too, which is used to build from the .i file.
........
  r2277 | garyo | 2007-08-14 10:40:00 -0500 (Tue, 14 Aug 2007) | 8 lines

  Test portability on IRIX: test/Actions/pre-post creates target file
  before building target, then IRIX CC does not chmod +x afterwards.
  I think this change is safe on all OSes.

  test/AS/ml.py: I think this is only supposed to be run on win32
  (not skipped only on win32); the sense of the skip test was backwards.
........
  r2278 | stevenknight | 2007-08-14 11:04:40 -0500 (Tue, 14 Aug 2007) | 2 lines

  Add -tt when running tests, to catch inconsistent tab usage.
........
  r2279 | stevenknight | 2007-08-14 14:00:43 -0500 (Tue, 14 Aug 2007) | 2 lines

  Minor refactor of logic in File.retrieve_from_cache().
........
  r2280 | stevenknight | 2007-08-15 01:11:40 -0500 (Wed, 15 Aug 2007) | 2 lines

  Refactor CacheDir support into its own module.
........
  r2281 | stevenknight | 2007-08-15 07:24:51 -0500 (Wed, 15 Aug 2007) | 2 lines

  Move the cachepath() method from FS.File to the CacheDir class.
........
  r2282 | stevenknight | 2007-08-15 08:31:34 -0500 (Wed, 15 Aug 2007) | 2 lines

  Python 1.5.2 fix in the new Null class.
........
  r2283 | stevenknight | 2007-08-15 10:45:53 -0500 (Wed, 15 Aug 2007) | 5 lines

  Refactor CacheDir unit tests to:
  - restore functionality that was dropped in the transition;
  - commonize creation of test Nodes and other (mock) objects
  - separate CacheDir tests from tests of CacheDir through Node.FS.File.
........
  r2284 | stevenknight | 2007-08-15 11:46:38 -0500 (Wed, 15 Aug 2007) | 3 lines

  Replace the Executor.Null.NullEnvironment object with a real Null object,
  so it will absorb the CacheDir method calls as well.
........
  r2285 | stevenknight | 2007-08-15 11:52:57 -0500 (Wed, 15 Aug 2007) | 5 lines

  Add a get_CacheDir() method to a construction environment, which will
  be used to fetch per-environment CacheDir specifications.  (Right now
  all calls to it still just return the one attached to underlying default
  FS object.)
........
  r2286 | stevenknight | 2007-08-15 15:15:46 -0500 (Wed, 15 Aug 2007) | 2 lines

  Support per-construction-environment configuration of CacheDir().
........
  r2287 | stevenknight | 2007-08-15 15:33:04 -0500 (Wed, 15 Aug 2007) | 2 lines

  Move the tests of CacheDir()-related command-line options into test/CacheDir.
........
  r2293 | stevenknight | 2007-08-16 11:14:49 -0500 (Thu, 16 Aug 2007) | 3 lines

  Add the Package() builder description to the documentation build,
  fixing the XML so that it will build.
........
  r2294 | stevenknight | 2007-08-16 12:51:19 -0500 (Thu, 16 Aug 2007) | 3 lines

  Reorganize packaging documentation:  alphabetize the variable definitions
  (and function names), document Tag() as a function, not a builder.
........
  r2296 | stevenknight | 2007-08-16 12:55:01 -0500 (Thu, 16 Aug 2007) | 2 lines

  Add a build command.
........
  r2300 | stevenknight | 2007-08-16 16:49:13 -0500 (Thu, 16 Aug 2007) | 2 lines

  First cut at documenting packaging variables.
........
  r2301 | stevenknight | 2007-08-16 16:51:21 -0500 (Thu, 16 Aug 2007) | 3 lines

  Construct the .src.rpm and .arch.rpm file names independnetly, not
  by trying to massage one into the other.
........

1 files changed, 562 insertions, 0 deletions

diff --git a/doc/user/less-simple.xml b/doc/user/less-simple.xml
new file mode 100644
index 0000000..eea3425
--- /dev/null
+++ b/doc/user/less-simple.xml
@@ -0,0 +1,562 @@
+<!--
+
+  __COPYRIGHT__
+
+  Permission is hereby granted, free of charge, to any person obtaining
+  a copy of this software and associated documentation files (the
+  "Software"), to deal in the Software without restriction, including
+  without limitation the rights to use, copy, modify, merge, publish,
+  distribute, sublicense, and/or sell copies of the Software, and to
+  permit persons to whom the Software is furnished to do so, subject to
+  the following conditions:
+
+  The above copyright notice and this permission notice shall be included
+  in all copies or substantial portions of the Software.
+
+  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
+  KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
+  WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+  NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
+  LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
+  OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+  WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+
+-->
+
+  <para>
+
+  In this chapter,
+  you will see several examples of
+  very simple build configurations using &SCons;,
+  which will demonstrate how easy
+  it is to use &SCons; to
+  build programs from several different programming languages
+  on different types of systems.
+
+  </para>
+
+  <section>
+  <title>Specifying the Name of the Target (Output) File</title>
+
+    <para>
+
+    You've seen that when you call the &b-link-Program; builder method,
+    it builds the resulting program with the same
+    base name as the source file.
+    That is, the following call to build an
+    executable program from the &hello_c; source file
+    will build an executable program named &hello; on POSIX systems,
+    and an executable program named &hello_exe; on Windows systems:
+
+    </para>
+
+    <programlisting>
+       Program('hello.c')
+    </programlisting>
+
+    <para>
+
+    If you want to build a program with
+    a different name than the base of the source file name,
+    you simply put the target file name
+    to the left of the source file name:
+
+    </para>
+
+    <programlisting>
+       Program('new_hello', 'hello.c')
+    </programlisting>
+
+    <para>
+
+    (&SCons; requires the target file name first,
+    followed by the source file name,
+    so that the order mimics that of an
+    assignment statement in most programming languages,
+    including Python:
+    <literal>"program = source files"</literal>.)
+
+    </para>
+
+    <para>
+
+    Now &SCons; will build an executable program
+    named &new_hello; when run on a POSIX system:
+
+    </para>
+
+    <screen>
+       % <userinput>scons -Q</userinput>
+       cc -o hello.o -c hello.c
+       cc -o new_hello hello.o
+    </screen>
+
+    <para>
+
+    And &SCons; will build an executable program
+    named &new_hello_exe; when run on a Windows system:
+
+    </para>
+
+    <screen>
+       C:\><userinput>scons -Q</userinput>
+       cl /nologo /c hello.c /Fohello.obj
+       link /nologo /OUT:new_hello.exe hello.obj
+    </screen>
+
+  </section>
+
+  <section>
+  <title>Compiling Multiple Source Files</title>
+
+    <para>
+
+    You've just seen how to configure &SCons;
+    to compile a program from a single source file.
+    It's more common, of course,
+    that you'll need to build a program from
+    many input source files, not just one.
+    To do this, you need to put the
+    source files in a Python list
+    (enclosed in square brackets),
+    like so:
+
+    </para>
+
+    <programlisting>
+       Program(['prog.c', 'file1.c', 'file2.c'])
+    </programlisting>
+
+    <para>
+
+    A build of the above example would look like:
+
+    </para>
+
+    <screen>
+       % <userinput>scons -Q</userinput>
+       cc -o file1.o -c file1.c
+       cc -o file2.o -c file2.c
+       cc -o prog.o -c prog.c
+       cc -o prog prog.o file1.o file2.o
+    </screen>
+
+    <para>
+
+    Notice that &SCons;
+    deduces the output program name
+    from the first source file specified
+    in the list--that is,
+    because the first source file was &prog_c;,
+    &SCons; will name the resulting program &prog;
+    (or &prog_exe; on a Windows system).
+    If you want to specify a different program name,
+    then (as we've seen in the previous section)
+    you slide the list of source files
+    over to the right
+    to make room for the output program file name.
+    (&SCons; puts the output file name to the left
+    of the source file names
+    so that the order mimics that of an
+    assignment statement:  "program = source files".)
+    This makes our example:
+
+    </para>
+
+    <programlisting>
+       Program('program', ['prog.c', 'file1.c', 'file2.c'])
+    </programlisting>
+
+    <para>
+
+    On Linux, a build of this example would look like:
+
+    </para>
+
+    <screen>
+       % <userinput>scons -Q</userinput>
+       cc -o file1.o -c file1.c
+       cc -o file2.o -c file2.c
+       cc -o prog.o -c prog.c
+       cc -o program prog.o file1.o file2.o
+    </screen>
+
+    <para>
+
+    Or on Windows:
+
+    </para>
+
+    <screen>
+       C:\><userinput>scons -Q</userinput>
+       cl /nologo /c file1.c /Fofile1.obj
+       cl /nologo /c file2.c /Fofile2.obj
+       cl /nologo /c prog.c /Foprog.obj
+       link /nologo /OUT:program.exe prog.obj file1.obj file2.obj
+    </screen>
+
+  </section>
+
+  <section>
+  <title>Specifying Single Files Vs. Lists of Files</title>
+
+    <para>
+
+    We've now shown you two ways to specify
+    the source for a program,
+    one with a list of files:
+
+    </para>
+
+    <programlisting>
+       Program('hello', ['file1.c', 'file2.c'])
+    </programlisting>
+
+    <para>
+
+    And one with a single file:
+
+    </para>
+
+    <programlisting>
+       Program('hello', 'hello.c')
+    </programlisting>
+
+    <para>
+
+    You could actually put a single file name in a list, too,
+    which you might prefer just for the sake of consistency:
+
+    </para>
+
+    <programlisting>
+       Program('hello', ['hello.c'])
+    </programlisting>
+
+    <para>
+
+    &SCons; functions will accept a single file name in either form.
+    In fact, internally, &SCons; treats all input as lists of files,
+    but allows you to omit the square brackets
+    to cut down a little on the typing
+    when there's only a single file name.
+
+    </para>
+
+    <important>
+    
+    <para>
+
+    Although &SCons; functions
+    are forgiving about whether or not you
+    use a string vs. a list for a single file name,
+    Python itself is more strict about
+    treating lists and strings differently.
+    So where &SCons; allows either
+    a string or list:
+
+    </para>
+
+    <programlisting>
+       # The following two calls both work correctly:
+       Program('program1', 'program1.c')
+       Program('program2', ['program2.c'])
+    </programlisting>
+
+    <para>
+
+    Trying to do "Python things" that mix strings and
+    lists will cause errors or lead to incorrect results:
+
+    </para>
+
+    <programlisting>
+       common_sources = ['file1.c', 'file2.c']
+
+       # THE FOLLOWING IS INCORRECT AND GENERATES A PYTHON ERROR
+       # BECAUSE IT TRIES TO ADD A STRING TO A LIST:
+       Program('program1', common_sources + 'program1.c')
+
+       # The following works correctly, because it's adding two
+       # lists together to make another list.
+       Program('program2', common_sources + ['program2.c'])
+    </programlisting>
+
+    </important>
+
+  </section>
+
+  <section>
+  <title>Making Lists of Files Easier to Read</title>
+
+    <para>
+
+    One drawback to the use of a Python list
+    for source files is that 
+    each file name must be enclosed in quotes
+    (either single quotes or double quotes).
+    This can get cumbersome and difficult to read
+    when the list of file names is long.
+    Fortunately, &SCons; and Python provide a number of ways
+    to make sure that
+    the &SConstruct; file stays easy to read.
+
+    </para>
+
+    <para>
+
+    To make long lists of file names
+    easier to deal with, &SCons; provides a
+    &Split; function
+    that takes a quoted list of file names,
+    with the names separated by spaces or other white-space characters,
+    and turns it into a list of separate file names.
+    Using the &Split; function turns the
+    previous example into:
+
+    </para>
+
+    <programlisting>
+       Program('program', Split('main.c file1.c file2.c'))
+    </programlisting>
+
+    <para>
+
+    (If you're already familiar with Python,
+    you'll have realized that this is similar to the
+    <function>split()</function> method
+    in the Python standard <function>string</function> module.
+    Unlike the <function>string.split()</function> method,
+    however, the &Split; function
+    does not require a string as input
+    and will wrap up a single non-string object in a list,
+    or return its argument untouched if it's already a list.
+    This comes in handy as a way to make sure
+    arbitrary values can be passed to &SCons; functions
+    without having to check the type of the variable by hand.)
+
+    </para>
+
+    <para>
+
+    Putting the call to the &Split; function
+    inside the &b-Program; call
+    can also be a little unwieldy.
+    A more readable alternative is to
+    assign the output from the &Split; call
+    to a variable name,
+    and then use the variable when calling the
+    &b-Program; function:
+
+    </para>
+
+    <programlisting>
+       list = Split('main.c file1.c file2.c')
+       Program('program', list)
+    </programlisting>
+
+    <para>
+
+    Lastly, the &Split; function
+    doesn't care how much white space separates
+    the file names in the quoted string.
+    This allows you to create lists of file
+    names that span multiple lines,
+    which often makes for easier editing:
+
+    </para>
+
+    <programlisting>
+       list = Split("""main.c
+                       file1.c
+                       file2.c""")
+       Program('program', list)
+    </programlisting>
+
+    <para>
+
+    (Note in this example that we used
+    the Python "triple-quote" syntax,
+    which allows a string to contain
+    multiple lines.
+    The three quotes can be either
+    single or double quotes.)
+
+    </para>
+
+  </section>
+
+  <section>
+  <title>Keyword Arguments</title>
+
+    <para>
+
+    &SCons; also allows you to identify
+    the output file and input source files
+    using Python keyword arguments.
+    The output file is known as the
+    <emphasis>target</emphasis>,
+    and the source file(s) are known (logically enough) as the
+    <emphasis>source</emphasis>.
+    The Python syntax for this is:
+
+    </para>
+
+    <programlisting>
+       list = Split('main.c file1.c file2.c')
+       Program(target = 'program', source = list)
+    </programlisting>
+
+    <para>
+
+    Because the keywords explicitly identify
+    what each argument is,
+    you can actually reverse the order if you prefer:
+
+    </para>
+
+    <programlisting>
+       list = Split('main.c file1.c file2.c')
+       Program(source = list, target = 'program')
+    </programlisting>
+
+    <para>
+
+    Whether or not you choose to use keyword arguments
+    to identify the target and source files,
+    and the order in which you specify them
+    when using keywords,
+    are purely personal choices;
+    &SCons; functions the same regardless.
+
+    </para>
+
+  </section>
+
+  <section>
+  <title>Compiling Multiple Programs</title>
+
+    <para>
+
+    In order to compile multiple programs
+    within the same &SConstruct; file,
+    simply call the &Program; method
+    multiple times,
+    once for each program you need to build:
+
+    </para>
+
+    <programlisting>
+       Program('foo.c')
+       Program('bar', ['bar1.c', 'bar2.c'])
+    </programlisting>
+
+    <para>
+
+    &SCons; would then build the programs as follows:
+
+    </para>
+
+    <screen>
+       % <userinput>scons -Q</userinput>
+       cc -o bar1.o -c bar1.c
+       cc -o bar2.o -c bar2.c
+       cc -o bar bar1.o bar2.o
+       cc -o foo.o -c foo.c
+       cc -o foo foo.o
+    </screen>
+
+    <para>
+
+    Notice that &SCons; does not necessarily build the
+    programs in the same order in which you specify
+    them in the &SConstruct; file.
+    &SCons; does, however, recognize that
+    the individual object files must be built
+    before the resulting program can be built.
+    We'll discuss this in greater detail in
+    the "Dependencies" section, below.
+
+    </para>
+
+  </section>
+
+  <section>
+  <title>Sharing Source Files Between Multiple Programs</title>
+
+    <para>
+
+    It's common to re-use code by sharing source files
+    between multiple programs.
+    One way to do this is to create a library
+    from the common source files,
+    which can then be linked into resulting programs.
+    (Creating libraries is discussed in
+    <xref linkend="chap-libraries"></xref>, below.)
+
+    </para>
+
+    <para>
+
+    A more straightforward, but perhaps less convenient,
+    way to share source files between multiple programs
+    is simply to include the common files
+    in the lists of source files for each program:
+
+    </para>
+
+    <programlisting>
+       Program(Split('foo.c common1.c common2.c'))
+       Program('bar', Split('bar1.c bar2.c common1.c common2.c'))
+    </programlisting>
+
+    <para>
+
+    &SCons; recognizes that the object files for
+    the &common1_c; and &common2_c; source files
+    each only need to be built once,
+    even though the resulting object files are
+    each linked in to both of the resulting executable programs:
+
+    </para>
+
+    <screen>
+       % <userinput>scons -Q</userinput>
+       cc -o bar1.o -c bar1.c
+       cc -o bar2.o -c bar2.c
+       cc -o common1.o -c common1.c
+       cc -o common2.o -c common2.c
+       cc -o bar bar1.o bar2.o common1.o common2.o
+       cc -o foo.o -c foo.c
+       cc -o foo foo.o common1.o common2.o
+    </screen>
+
+    <para>
+
+    If two or more programs
+    share a lot of common source files,
+    repeating the common files in the list for each program
+    can be a maintenance problem when you need to change the
+    list of common files.
+    You can simplify this by creating a separate Python list
+    to hold the common file names,
+    and concatenating it with other lists
+    using the Python &plus; operator:
+
+    </para>
+
+    <programlisting>
+       common = ['common1.c', 'common2.c']
+       foo_files = ['foo.c'] + common
+       bar_files = ['bar1.c', 'bar2.c'] + common
+       Program('foo', foo_files)
+       Program('bar', bar_files)
+    </programlisting>
+
+    <para>
+
+    This is functionally equivalent to the previous example.
+
+    </para>
+
+  </section>