<!-- __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.--><!--=head1 Why Cons? Why not Make?Cons is a B<make> replacement. In the following paragraphs, we look at a fewof the undesirable characteristics of make, and typical build environmentsbased on make, that motivated the development of Cons.=head2 Build complexityTraditional make-based systems of any size tend to become quite complex. Theoriginal make utility and its derivatives have contributed to this tendencyin a number of ways. Make is not good at dealing with systems that arespread over multiple directories. Various work-arounds are used to overcomethis difficulty; the usual choice is for make to invoke itself recursivelyfor each sub-directory of a build. This leads to complicated code, in whichit is often unclear how a variable is set, or what effect the setting of avariable will have on the build as a whole. The make scripting language hasgradually been extended to provide more possibilities, but these havelargely served to clutter an already overextended language. Often, buildsare done in multiple passes in order to provide appropriate products fromone directory to another directory. This represents a further increase inbuild complexity.=head2 Build reproducibilityThe bane of all makes has always been the correct handling ofdependencies. Most often, an attempt is made to do a reasonable job ofdependencies within a single directory, but no serious attempt is made to dothe job between directories. Even when dependencies are working correctly,make's reliance on a simple time stamp comparison to determine whether afile is out of date with respect to its dependents is not, in general,adequate for determining when a file should be rederived. If an externallibrary, for example, is rebuilt and then ``snapped'' into place, thetimestamps on its newly created files may well be earlier than the lastlocal build, since it was built before it became visible.=head2 Variant buildsMake provides only limited facilities for handling variant builds. With theproliferation of hardware platforms and the need for debuggablevs. optimized code, the ability to easily create these variants isessential. More importantly, if variants are created, it is important toeither be able to separate the variants or to be able to reproduce theoriginal or variant at will. With make it is very difficult to separate thebuilds into multiple build directories, separate from the source. And ifthis technique isn't used, it's also virtually impossible to guarantee atany given time which variant is present in the tree, without resorting to acomplete rebuild.=head2 RepositoriesMake provides only limited support for building software from code thatexists in a central repository directory structure. The VPATH feature ofGNU make (and some other make implementations) is intended to provide this,but doesn't work as expected: it changes the path of target file to theVPATH name too early in its analysis, and therefore searches for alldependencies in the VPATH directory. To ensure correct development builds,it is important to be able to create a file in a local build directory andhave any files in a code repository (a VPATH directory, in make terms) thatdepend on the local file get rebuilt properly. This isn't possible withVPATH, without coding a lot of complex repository knowledge directly intothe makefiles.--><para> XXX
</para><section><title>Differences Between &Make; and &SCons;</title><para> XXX
</para></section><section><title>Advantages of &SCons; Over &Make;</title><para> XXX
</para></section>