diff options
Diffstat (limited to 'doc/python10/intro.xml')
| -rw-r--r-- | doc/python10/intro.xml | 212 |
1 files changed, 212 insertions, 0 deletions
diff --git a/doc/python10/intro.xml b/doc/python10/intro.xml new file mode 100644 index 0000000..d3057be --- /dev/null +++ b/doc/python10/intro.xml @@ -0,0 +1,212 @@ +<para> + + More than twenty years after its creation, the classic UNIX &Make; + utility and its descendants are still the dominant way in which + software is built. &Make; has maintained this position despite the + fact that the intervening years have revealed many + shortcomings of the &Make; model for building software: + +</para> + +<itemizedlist> + + <listitem> + <para> + + The use of timestamps to decide when a file has been updated is + imprecise and prone to error, especially across distributed file + systems such as NFS. + + </para> + </listitem> + + <listitem> + <para> + + Builds of typical large software systems still take hours, if not + days, despite the tremendous advances in CPU and disk speeds over + recent years. + + </para> + </listitem> + + <listitem> + <para> + + &Make; maintains static definitions of dependencies in its + &Makefiles;. Much effort has been put into + utilities (<application>mkdepend</application>, <application>gcc + -M</application>) and schemes (<filename>Makefile.d</filename> + files) to try to keep &Makefile; dependencies up-to-date, + but these only confirm that &Make;'s static dependencies are + inherently fragile. + + </para> + </listitem> + + <listitem> + <para> + + The standard recursive use of &Make; for build hierarchies leads + to incomplete dependency graphs, which must be overcome by + manually changing the order in which directories are built, or + through the use of multiple build passes. + + </para> + </listitem> + +</itemizedlist> + +<para> + + One need only look at the plethora of helper and wrapper utilities + (automake, easymake, imake, jmake, makeLib, maketool, mkmed, shake, + SMake, TMAKE) and complete alternatives to &Make; (Ant, bake, bau, + bras, Cake, Cons, Cook, Jam, jmk, jus, makeme, mash, MK, nmake, Odin, + VMake) that have been created over the years to realize that vanilla + &Make; is not satisfying everyone's build requirements. So why Yet + Another build tool? + +</para> + +<section> + <title>Enter Software Carpentry</title> + + <para> + + Most of the build tools just mentioned + were written by programmers and for + programmers. The fact that most programmer-friendly + utilities do a poor job of fulfilling the needs + of non-programmers prompted Greg Wilson to + organize the Software Carpentry competition in January 2000. + Software Carpentry was an + open design contest with the express goal of producing a set of + next-generation utilities, including a build tool, that would be + accessible + not only to + programmers + but also to computer <emphasis>users</emphasis> + such as physical scientists. + + </para> + + <para> + + The key to this usability would be that all of + these utilities, including the build tool, would be + written in Python. + This provided the catalyst for actually + pursuing an idea + that had been floating around one of the more + intriguing &Make; alternatives, + a Perl utility called &Cons;. + What if the friendlier syntax of Python + could be married to the + architectural advantages of &Cons;? + + </para> + + <para> + + The resulting merged design, at that time named &ScCons;, + won the Software Carpentry build tool competition. CodeSourcery (by + then the administrators of the competition) ultimately decided not to + fund development of the build tool, but the seed had been planted and the + design had taken root. + + </para> + +</section> + +<section> + <title>Cons</title> + + <para> + + It helps to know something about &Cons;. + &Cons; was first released in 1996 by Bob Sidebotham, + then an employee of Fore Systems, + and it has a number of + distinctive features that set it apart from most &Make;-alikes: + + </para> + + <itemizedlist> + + <listitem> + <para> + + &Cons; "configuration files" are not Yet Another + invented mini-language, but are actually <emphasis>Perl + scripts</emphasis>, which means the full power and flexibility of + a real scripting language can be applied to build problems. + + </para> + </listitem> + + <listitem> + <para> + + &Cons; builds everything from a single process at the top of the + source tree, with a global view of the dependencies. + + </para> + </listitem> + + <listitem> + <para> + + &Cons; scans files automatically for dependencies such as + files specified on <literal>#include</literal> lines. + + </para> + </listitem> + + <listitem> + <para> + + &Cons; decides if a file was out-of-date by using MD5 checksums of + the contents of files, not timestamps. + + </para> + </listitem> + + </itemizedlist> + + <para> + + Despite all of these intriguing architectural features, the great + strength of &Cons;—being written in Perl—was also one of + its weaknesses, turning away many potential users due to the + (real or perceived) steep learning curve of Perl. + + </para> + +</section> + +<section> + <title>&SCons;</title> + + <para> + + Through the &ScCons; contest entry, + &SCons; is the direct descendant of the &Cons; architecture, + and is currently + under active, supported development with a growing body of + users. Its first release was 13 December 2001, under the simple and + non-restrictive MIT license, and from the outset, the goal of the + members of the &SCons; project has been to deliver a stable, reliable + tool that can be used for industrial-strength software builds. + + </para> + + <para> + + The rest of this paper will give an overview of the &SCons; design + (including its architecture and interface), describe the development + methodology used, and discuss future directions for &SCons;. + + </para> + +</section> |