File: cons.html

package info (click to toggle)
cons 1.5-1
links: PTS
area: main
in suites: potato
size: 492 kB
ctags: 217
sloc: perl: 1,602; makefile: 32; sh: 17
file content (2630 lines) | stat: -rw-r--r-- 86,031 bytes
    <HTML> 
	<HEAD> 
	    <TITLE>Cons - Cons: A Software Construction System

</TITLE> 
	</HEAD>

	<BODY>

<!-- INDEX BEGIN -->

<UL>

	<LI><A HREF="#NAME">NAME</A>
	<LI><A HREF="#DESCRIPTION">DESCRIPTION</A>
	<LI><A HREF="#B_Cons_A_Software_Construction_"><STRONG>Cons: A Software Construction System</STRONG></A>
	<LI><A HREF="#B_Introduction_"><STRONG>Introduction</STRONG></A>
	<LI><A HREF="#B_Why_Cons_Why_not_Make_"><STRONG>Why Cons? Why not Make?</STRONG></A>
	<LI><A HREF="#B_Keeping_it_simple_"><STRONG>Keeping it simple</STRONG></A>
	<LI><A HREF="#B_Building_large_trees_still_ju"><STRONG>Building large trees-still just as simple</STRONG></A>
	<LI><A HREF="#B_A_Model_for_sharing_files_"><STRONG>A Model for sharing files</STRONG></A>
	<LI><A HREF="#B_Separating_source_and_build_tr"><STRONG>Separating source and build trees</STRONG></A>
	<LI><A HREF="#B_Variant_builds_"><STRONG>Variant builds</STRONG></A>
	<LI><A HREF="#B_Signatures_"><STRONG>Signatures</STRONG></A>
	<LI><A HREF="#B_Code_Repositories_"><STRONG>Code Repositories</STRONG></A>
	<LI><A HREF="#B_Selective_builds_"><STRONG>Selective builds</STRONG></A>
	<LI><A HREF="#B_Build_Pruning_"><STRONG>Build Pruning</STRONG></A>
	<LI><A HREF="#B_Backing_builds_"><STRONG>Backing builds</STRONG></A>
	<LI><A HREF="#B_Temporary_overrides_"><STRONG>Temporary overrides</STRONG></A>
	<LI><A HREF="#B_More_on_construction_environme"><STRONG>More on construction environments:Default construction variables</STRONG></A>
	<LI><A HREF="#B_Default_construction_methods_"><STRONG>Default construction methods</STRONG></A>
	<LI><A HREF="#B_Extending_Cons_"><STRONG>Extending Cons</STRONG></A>
	<LI><A HREF="#B_Invoking_Cons_"><STRONG>Invoking Cons</STRONG></A>
	<LI><A HREF="#B_Using_and_writing_dependency_s"><STRONG>Using and writing dependency scanners</STRONG></A>
</UL>
<!-- INDEX END -->

<HR>
<P>
<H1><A NAME="NAME">NAME

</A></H1>
Cons - Cons: A Software Construction System


<P>

<P>
<HR>
<H1><A NAME="DESCRIPTION">DESCRIPTION

</A></H1>
The original document was automatically derived from the <EM>cons/cons.html</EM>
by <STRONG>html2pod</STRONG>, thanks to Ulrich Pfiefer. Later revisions were created from the original.


<P>

<P>
<HR>
<H1><A NAME="B_Cons_A_Software_Construction_"><STRONG>Cons: A Software Construction System</STRONG>

</A></H1>
by Bob Sidebotham <EM>rns@fore.com</EM>




<P>

A guide and reference for version 1.3.1


<P>

Copyright (c) 1996-1998 FORE Systems, Inc. All rights reserved.


<P>

Permission to use, copy, modify and distribute this software and its
documentation for any purpose and without fee is hereby granted, provided
that the above copyright notice appear in all copies and that both that
copyright notice and this permission notice appear in supporting
documentation, and that the name of FORE Systems, Inc. (``FORE Systems'')
not be used in advertising or publicity pertaining to distribution of the
software without specific, written prior permission.


<P>

FORE SYSTEMS DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
INCLUDING ANY WARRANTIES REGARDING INTELLECTUAL PROPERTY RIGHTS AND ALL
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
IN NO EVENT SHALL FORE SYSTEMS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
PERFORMANCE OF THIS SOFTWARE.


<P>

<P>
<HR>
<H1><A NAME="B_Introduction_"><STRONG>Introduction</STRONG>

</A></H1>
<STRONG>Cons</STRONG> is a system for constructing, primarily, software, but is quite different
from previous software construction systems. Cons was designed from the
ground up to deal easily with the construction of software spread over
multiple source directories. Cons makes it easy to create build scripts
that are simple, understandable and maintainable. Cons ensures that complex
software is easily and accurately reproducible.


<P>

Cons uses a number of techniques to accomplish all of this. Construction
scripts are just Perl scripts, making them both easy to comprehend and very
flexible. Global scoping of variables is replaced with an import/export
mechanism for sharing information between scripts, significantly improving
the readability and maintainability of each script. <STRONG>Construction environments</STRONG> are introduced: these are Perl objects that capture the information
required for controlling the build process. Multiple environments are used
when different semantics are required for generating products in the build
tree. Cons implements automatic dependency analysis and uses this to
globally sequence the entire build. Variant builds are easily produced from
a single source tree. Intelligent build subsetting is possible, when
working on localized changes. Overrides can be setup to easily override
build instructions without modifying any scripts. MD5 cryptographic <STRONG>signatures</STRONG> are associated with derived files, and are used to accurately determine
whether a given file needs to be rebuilt.


<P>

While offering all of the above, and more, Cons remains simple and easy to
use. This will, hopefully, become clear as you read the remainder of this
document.


<P>

<P>
<HR>
<H1><A NAME="B_Why_Cons_Why_not_Make_"><STRONG>Why Cons? Why not Make?</STRONG>

</A></H1>
Cons is a <STRONG>make</STRONG> replacement. In the following paragraphs, we look at a few of the
undesirable characteristics of make--and typical build environments based
on make--that motivated the development of Cons.


<P>

<DL>
<DT><STRONG><A NAME="item_Build">Build complexity

</A></STRONG><DD>
Traditional make-based systems of any size tend to become quite complex.
The original make utility and its derivatives have contributed to this
tendency in a number of ways. Make is not good at dealing with systems that
are spread over multiple directories. Various work-arounds are used to
overcome this difficulty; the usual choice is for make to invoke itself
recursively for each sub-directory of a build. This leads to complicated
code, in which it is often unclear how a variable is set, or what effect
the setting of a variable will have on the build as a whole. The make
scripting language has gradually been extended to provide more
possibilities, but these have largely served to clutter an already over
extended language. Often, builds are done in multiple passes in order to
provide appropriate products from one directory to another directory. This
represents a further increase in build complexity.


<P>

<DT><STRONG>Build reproducibility 

</A></STRONG><DD>
The bane of all makes has always been the correct handling of dependencies.
Most often, an attempt is made to do a reasonable job of dependencies
within a single directory, but no serious attempt is made to do the job
between directories. Even when dependencies are working correctly, make's
reliance on a simple time stamp comparison to determine whether a file is
out of date with respect to its dependents is not, in general, adequate for
determining when a file should be rederived. If an external library, for
example, is rebuilt and then ``snapped'' into place, the timestamps on its
newly created files may well be earlier than the last local build, since it
was built before it became visible.


<P>

<DT><STRONG><A NAME="item_Variant">Variant builds

</A></STRONG><DD>
Make provides only limited facilities for handling variant builds. With the
proliferation of hardware platforms and the need for debuggable vs.
optimized code, the ability to easily create these variants is essential.
More importantly, if variants are created, it is important to either be
able to separate the variants or to be able to reproduce the original or
variant at will. With make it is very difficult to separate the builds into
multiple build directories, separate from the source. And if this technique
isn't used, it's also virtually impossible to guarantee at any given time
which variant is present in the tree, without resorting to a complete
rebuild.


<P>

<DT><STRONG><A NAME="item_Repositories">Repositories

</A></STRONG><DD>
Make provides only limited support for building software from code that
exists in a central repository directory structure. The VPATH feature of
GNU 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 the
VPATH name too early in its analysis, and therefore searches for all
dependencies in the VPATH directory. To ensure correct development builds,
it is important to be able to create a file in a local build directory and
have any files in a code repository (a VPATH directory, in make terms) that
depend on the local file get rebuilt properly. This isn't possible with
VPATH, without coding a lot of complex repository knowledge directly into
the makefiles.


<P>

<H1><A NAME="B_Keeping_it_simple_"><STRONG>Keeping it simple</STRONG>

</A></H1>
A few of the difficulties with make have been cited above. In this and
subsequent sections, we shall introduce Cons and show how these issues are
addressed.


<P>

<DT><STRONG><A NAME="item_Perl">Perl scripts

</A></STRONG><DD>
Cons is Perl-based. That is, Cons scripts--<CODE>Conscript</CODE> and <CODE>Construct</CODE> files, the equivalent to <CODE>makefiles</CODE>--are all written in Perl. This provides an immediate benefit: the language
for writing scripts is a familiar one. Even if you don't happen to be a
Perl programmer, it helps to know that Perl is basically just a simple
declarative language, with a well-defined flow of control, and familiar
semantics. It has variables that behave basically the way you would expect
them to, subroutines, flow-of-control, and so on. There is no special
syntax introduced for Cons. The use of Perl as a scripting language
simplifies the task of expressing the appropriate solution to the often
complex requirements of a build.


<P>

<DT><STRONG><A NAME="item_Hello">Hello, World!

</A></STRONG><DD>
To ground the following discussion, here's how you could build the <STRONG>Hello, World!</STRONG> C application with Cons:


<P>

<PRE>  $env = new cons();
  Program $env 'hello', 'hello.c';
</PRE>

<P>

If you install this script in a directory, naming the script <CODE>Construct,</CODE> and create the <CODE>hello.c</CODE> source file in the same directory, then you can type <CODE>cons hello</CODE> to build the application:


<P>

<PRE>  % cons hello
  cc -c hello.c -o hello.o
  cc -o hello hello.o
</PRE>

<P>

<DT><STRONG><A NAME="item_Construction">Construction environments

</A></STRONG><DD>
A key simplification of Cons is the idea of a <STRONG>construction environment</STRONG>. A construction environment is an <STRONG>object</STRONG> characterized by a set of key/value pairs and a set of <STRONG>methods. </STRONG>In order to tell Cons how to build something, you invoke the appropriate
method via an appropriate construction environment. Consider the following
example:


<P>

<PRE>  $env = new cons(
        CC      =&gt;      'gcc',
        LIBS    =&gt;      'libworld.a'
  );
  
  Program $env 'hello', 'hello.c';
</PRE>

<P>

In this case, rather than using the default construction environment, as
is, we have overridden the value of <CODE>CC</CODE> so that the GNU C Compiler equivalent is used, instead. Since this version
of <STRONG>Hello, World!</STRONG> requires a library, <CODE>libworld.a</CODE>, we have specified that any program linked in this environment should be
linked with that library. If the library exists already, well and good, but
if not, then we'll also have to include the statement:


<P>

<PRE>  Library $env 'libworld', 'world.c';
</PRE>

<P>

Now if you type <CODE>cons hello</CODE>, the library will be built before the program is linked, and, of course, <CODE>gcc</CODE> will be used to compile both modules:


<P>

<PRE>  % cons hello
  gcc -c hello.c -o hello.o
  gcc -c world.c -o world.o
  ar r libworld.a world.o
  ar: creating libworld.a
  ranlib libworld.a
  gcc -o hello hello.o libworld.a
</PRE>

<P>

<DT><STRONG><A NAME="item_Automatic">Automatic and complete dependency analysis

</A></STRONG><DD>
With Cons, dependencies are handled automatically. Continuing the previous
example, note that when we modify <CODE>world.c</CODE>, <CODE>world.o</CODE> is recompiled, <CODE>libworld.a</CODE> recreated, and <CODE>hello</CODE> relinked:


<P>

<PRE>  % touch world.c
  % cons hello
  gcc -c world.c -o world.o
  ar r libworld.a world.o
  ar: creating libworld.a
  ranlib libworld.a
  gcc -o hello hello.o libworld.a
</PRE>

<P>

This is a relatively simple example: Cons ``knows'' world.o depends upon <CODE>world.c</CODE>, because the dependency is explicitly set up by the <CODE>Library</CODE> method. It also knows that <CODE>libworld.a</CODE> depends upon <CODE>world.o</CODE> and that <CODE>hello</CODE> depends upon <CODE>libworld.a</CODE>, all for similar reasons.


<P>

Now it turns out that <CODE>hello.c</CODE> also includes the interface definition file, <CODE>world.h</CODE>:


<P>

<PRE>  % touch world.h
  % cons hello
  gcc -c hello.c -o hello.o
  gcc -o hello hello.o libworld.a
</PRE>

<P>

How does Cons know that <CODE>hello.c</CODE> includes <CODE>world.h</CODE>, and that <CODE>hello.o</CODE> must therefore be recompiled? For now, suffice it to say that when
considering whether or not <CODE>hello.o</CODE> is up-to-date, Cons invokes a scanner for its dependency, <CODE>hello.c</CODE>. This scanner enumerates the files included by <CODE>hello.c</CODE> to come up with a list of further dependencies, beyond those made explicit
by the Cons script. This process is recursive: any files included by
included files will also be scanned.


<P>

Isn't this expensive? The answer is--it depends. If you do a full build of
a large system, the scanning time is insignificant. If you do a rebuild of
a large system, then Cons will spend a fair amount of time thinking about
it before it decides that nothing has to be done (although not necessarily
more time than make!). The good news is that Cons makes it very easy to
intelligently subset your build, when you are working on localized changes.


<P>

<DT><STRONG>Automatic global build sequencing

</A></STRONG><DD>
Because Cons does full and accurate dependency analysis, and does this
globally, for the entire build, Cons is able to use this information to
take full control of the <STRONG>sequencing</STRONG> of the build. This sequencing is evident in the above examples, and is
equivalent to what you would expect for make, given a full set of
dependencies. With Cons, this extends trivially to larger, multi-directory
builds. As a result, all of the complexity involved in making sure that a
build is organized correctly--including multi-pass hierarchical builds--is
eliminated. We'll discuss this further in the next sections.


<P>

<H1><A NAME="B_Building_large_trees_still_ju"><STRONG>Building large trees--still just as simple</STRONG>

</A></H1>
<DT><STRONG><A NAME="item_A">A hierarchy of build scripts

</A></STRONG><DD>
A larger build, in Cons, is organized by creating a hierarchy of <STRONG>build scripts</STRONG>. At the top of the tree is a script called <CODE>Construct</CODE>. The rest of the scripts, by convention, are each called <CODE>Conscript</CODE>. These scripts are connected together, very simply, by the <A HREF="#item_Build">Build</A>, <CODE>Export</CODE>, and <CODE>Import</CODE> commands.


<P>

<DT><STRONG><A NAME="item_The">The Build command

</A></STRONG><DD>
The <A HREF="#item_Build">Build</A> command takes a list of <CODE>Conscript</CODE> file names, and arranges for them to be included in the build. For example:


<P>

<PRE>  Build qw(
        drivers/display/Conscript
        drivers/mouse/Conscript
        parser/Conscript
        utilities/Conscript
  );
</PRE>

<P>

This is a simple two-level hierarchy of build scripts: all the subsidiary <CODE>Conscript</CODE> files are mentioned in the top-level <CODE>Construct</CODE> file. Notice that not all directories in the tree necessarily have build
scripts associated with them.


<P>

This could also be written as a multi-level script. For example, the <CODE>Construct</CODE> file might contain this command:


<P>

<PRE>  Build qw(
        parser/Conscript
        drivers/Conscript
        utilities/Conscript
  );
</PRE>

<P>

and the <CODE>Conscript</CODE> file in the <CODE>drivers</CODE> directory might contain this:


<P>

<PRE>  
  Build qw(
        display/Conscript
        mouse/Conscript
  );
</PRE>

<P>

Experience has shown that the former model is a little easier to
understand, since the whole construction tree is laid out in front of you,
at the top-level. Hybrid schemes are also possible. A separately maintained
component that needs to be incorporated into a build tree, for example,
might hook into the build tree in one place, but define its own
construction hierarchy.


<P>

<DT><STRONG><A NAME="item_Relative">Relative, top-relative, and absolute file names

</A></STRONG><DD>
You may have noticed that the file names specified to the Build command are
relative to the location of the script it is invoked from. This is
generally true for other filename arguments to other commands, too,
although we might as well mention here that if you begin a file name with a
hash mark, ``#'', then that file is interpreted relative to the top-level
directory (where the Construct file resides). And, not surprisingly, if you
begin it with ``/'', then it is considered to be an absolute pathname. This
is true even on systems which use a back slash rather than a forward slash
to name absolute paths.


<P>

<DT><STRONG><A NAME="item_Scope">Scope of variables

</A></STRONG><DD>
Each <CODE>Conscript</CODE> file, and also the top-level <CODE>Construct</CODE> file, begins life in a separate Perl package. Except for the <CODE>Construct</CODE> file, which gets some of the command line arguments, the symbol table for
each script is empty. All of the variables that are set, therefore, are set
by the script itself--not by some external script. Variables can be
explicitly <STRONG>imported</STRONG> by a script from its parent script. To import a variable, it must have been <STRONG>exported</STRONG> by the parent and initialized (otherwise an error will occur). It is
therefore possible to determine, from looking at a single script, exactly
where each variable in that script is set.


<P>

<DT><STRONG>The Export command

</A></STRONG><DD>
The <CODE>Export</CODE> command is used as in the following example:


<P>

<PRE>  $ENV = new cons();
  $INCLUDE = &quot;#export/include&quot;;
  $LIB = &quot;#export/lib&quot;;
  Export qw( ENV INCLUDE LIB );
  Build qw( util/Conscript );
</PRE>

<P>

The values of the simple variables mentioned in the <CODE>Export</CODE> list will be squirreled away by any subsequent <A HREF="#item_Build">Build</A> commands. The <CODE>Export</CODE> command will only export Perl<STRONG><PRE> scalar
</PRE>
</STRONG> variables, that is, variables whose name begins with <CODE>$</CODE>. Other variables, objects, etc. can be exported by reference--but all
scripts will refer to the same object, and this object should be considered
to be read-only by the subsidiary scripts and by the original exporting
script. It's acceptable, however, to assign a new value to the exported
scalar variable--that won't change the underlying variable referenced. This
sequence, for example, is OK:


<P>

<PRE>  $ENV = new cons();
  Export qw( ENV INCLUDE LIB );
  Build qw( util/Conscript );
  $ENV = new cons(CFLAGS =&gt; '-O');
  Build qw( other/Conscript );
</PRE>

<P>

It doesn't matter whether the variable is set before or after the <CODE>Export</CODE> command. The important thing is the value of the variable at the time the <A HREF="#item_Build">Build</A> command is executed. This is what gets squirreled away. Any subsequent <CODE>Export</CODE> commands, by the way, invalidate the first: you must mention all the
variables you wish to export on each <CODE>Export</CODE> command.


<P>

<DT><STRONG>The Import command

</A></STRONG><DD>
Variables exported by the <CODE>Export</CODE> command can be imported into subsidiary scripts by the <CODE>Import</CODE> command. The subsidiary script always imports variables directly from the
superior script. Consider this example:


<P>

<PRE>  Import qw( ENV INCLUDE );
</PRE>

<P>

This is only legal if the parent script exported both <CODE>$ENV</CODE> and <CODE>$INCLUDE</CODE>. It also must have given each of these variables values. It is OK for the
subsidiary script to only import a subset of the exported variables (in
this example, <CODE>$LIB</CODE>, which was exported by the previous example, is not imported).


<P>

All the imported variables are automatically re-exported, so the sequence:


<P>

<PRE>  Import qw ( ENV INCLUDE );
  Build qw ( beneath-me/Conscript );
</PRE>

<P>

will supply both <CODE>$ENV</CODE> and <CODE>$INCLUDE</CODE> to the subsidiary file. If only <CODE>$ENV</CODE> is to be exported, then the following will suffice:


<P>

<PRE>  Import qw ( ENV INCLUDE );
  Export qw ( ENV );
  Build qw ( beneath-me/Conscript );
</PRE>

<P>

Needless to say, the variables may be modified locally before invoking <A HREF="#item_Build">Build</A> on the subsidiary script.


<P>

<DT><STRONG>Build script evaluation order

</A></STRONG><DD>
The only constraint on the ordering of build scripts is that superior
scripts are evaluated before their inferior scripts. The top-level <CODE>Construct</CODE> file, for instance, is evaluated first, followed by any inferior scripts.
This is all you really need to know about the evaluation order, since order
is generally irrelevant. Consider the following <A HREF="#item_Build">Build</A> command:


<P>

<PRE>  Build qw(
        drivers/display/Conscript
        drivers/mouse/Conscript
        parser/Conscript
        utilities/Conscript
  );
</PRE>

<P>

We've chosen to put the script names in alphabetical order, simply because
that's the most convenient for maintenance purposes. Changing the order
will make no difference to the build.


<P>

<H1><A NAME="B_A_Model_for_sharing_files_"><STRONG>A Model for sharing files</STRONG>

</A></H1>
<DT><STRONG><A NAME="item_Some">Some simple conventions

</A></STRONG><DD>
In any complex software system, a method for sharing build products needs
to be established. We propose a simple set of conventions which are trivial
to implement with Cons, but very effective.


<P>

The basic rule is to require that all build products which need to be
shared between directories are shared via an intermediate directory. We
have typically called this <CODE>export</CODE>, and, in a C environment, provided conventional sub-directories of this
directory, such as <CODE>include</CODE>, <CODE>lib</CODE>, <CODE>bin</CODE>, etc.


<P>

These directories are defined by the top-level <CODE>Construct</CODE> file. A simple <CODE>Construct</CODE> file for a <STRONG>Hello, World!</STRONG> application, organized using multiple directories, might look like this:


<P>

<PRE>  # Construct file for Hello, World!
  
  # Where to put all our shared products.
  $EXPORT = '#export';
  
  Export qw( CONS INCLUDE LIB BIN );
</PRE>

<P>

<PRE>  # Standard directories for sharing products.
  $INCLUDE = &quot;$EXPORT/include&quot;;
  $LIB = &quot;$EXPORT/lib&quot;;
  $BIN = &quot;$EXPORT/bin&quot;;
  
  # A standard construction environment.
  $CONS = new cons (
        CPPPATH =&gt; $INCLUDE,                    # Include path for C Compilations
        LIBPATH =&gt; $LIB         ,       # Library path for linking programs
        LIBS =&gt; '-lworld',                      # List of standard libraries
  );
</PRE>

<P>

<PRE>  Build qw(
        hello/Conscript 
        world/Conscript
  );
</PRE>

<P>

The <CODE>world</CODE> directory's <CODE>Conscript</CODE> file looks like this:


<P>

<PRE>  # Conscript file for directory world
  Import qw( CONS INCLUDE LIB );
</PRE>

<P>

<PRE>  # Install the products of this directory
  Install $CONS $LIB, 'libworld.a';
  Install $CONS $INCLUDE, 'world.h';
</PRE>

<P>

<PRE>  # Internal products
  Library $CONS 'libworld.a', 'world.c';
</PRE>

<P>

and the <CODE>hello</CODE> directory's <CODE>Conscript</CODE> file looks like this:


<P>

<PRE>  # Conscript file for directory hello
  Import qw( CONS BIN );
  
  # Exported products
  Install $CONS $BIN, 'hello';
  
  # Internal products
  Program $CONS 'hello', 'hello.c';
</PRE>

<P>

To construct a <STRONG>Hello, World!</STRONG> program with this directory structure, go to the top-level directory, and
invoke <CODE>cons</CODE> with the appropriate arguments. In the following example, we tell Cons to
build the directory <CODE>export</CODE>. To build a directory, Cons recursively builds all known products within
that directory (only if they need rebuilding, of course). If any of those
products depend upon other products in other directories, then those will
be built, too.


<P>

<PRE>  % cons export
  Install world/world.h as export/include/world.h
  cc -Iexport/include -c hello/hello.c -o hello/hello.o
  cc -Iexport/include -c world/world.c -o world/world.o
  ar r world/libworld.a world/world.o
  ar: creating world/libworld.a
  ranlib world/libworld.a
  Install world/libworld.a as export/lib/libworld.a
  cc -o hello/hello hello/hello.o -Lexport/lib -lworld
  Install hello/hello as export/bin/hello
</PRE>

<P>

<DT><STRONG><A NAME="item_Clean">Clean, understandable, location-independent scripts

</A></STRONG><DD>
You'll note that the two <CODE>Conscript</CODE> files are very clean and to-the-point. They simply specify products of the
directory and how to build those products. The build instructions are
minimal: they specify which construction environment to use, the name of
the product, and the name of the inputs. Note also that the scripts are
location-independent: if you wish to reorganize your source tree, you are
free to do so: you only have to change the <CODE>Construct</CODE> file (in this example), to specify the new locations of the <CODE>Conscript</CODE> files. The use of an export tree makes this goal easy.


<P>

Note, too, how Cons takes care of little details for you. All the <CODE>export</CODE> directories, for example, were made automatically. And the installed files
were really hard-linked into the respective export directories, to save
space and time. This attention to detail saves considerable work, and makes
it even easier to produce simple, maintainable scripts.


<P>

<H1><A NAME="B_Separating_source_and_build_tr"><STRONG>Separating source and build trees</STRONG>

</A></H1>
It's often desirable to keep any derived files from the build completely
separate from the source files. This makes it much easier to keep track of
just what is a source file, and also makes it simpler to handle <STRONG>variant</STRONG> builds, especially if you want the variant builds to co-exist.


<P>

<DT><STRONG><A NAME="item_Separating">Separating build and source directories using the Link command

</A></STRONG><DD>
Cons provides a simple mechanism that handles all of these requirements.
The <CODE>Link</CODE> command is invoked as in this example:


<P>

<PRE>  Link 'build' =&gt; 'src';
</PRE>

<P>

The specified directories are ``linked'' to the specified source directory.
Let's suppose that you setup a source directory, <CODE>src</CODE>, with the sub-directories <CODE>world</CODE> and <CODE>hello</CODE> below it, as in the previous example. You could then substitute for the
original build lines the following:


<P>

<PRE>  Build qw(
        build/world/Conscript
        build/hello/Conscript
  );
</PRE>

<P>

Notice that you treat the <CODE>Conscript</CODE> file as if it existed in the build directory. Now if you type the same
command as before, you will get the following results:


<P>

<PRE>  % cons export
  Install build/world/world.h as export/include/world.h
  cc -Iexport/include -c build/hello/hello.c -o build/hello/hello.o
  cc -Iexport/include -c build/world/world.c -o build/world/world.o
  ar r build/world/libworld.a build/world/world.o
  ar: creating build/world/libworld.a
  ranlib build/world/libworld.a
  Install build/world/libworld.a as export/lib/libworld.a
  cc -o build/hello/hello build/hello/hello.o -Lexport/lib -lworld
  Install build/hello/hello as export/bin/hello
</PRE>

<P>

Again, Cons has taken care of the details for you. In particular, you will
notice that all the builds are done using source files and object files
from the build directory. For example, <CODE>build/world/world.o</CODE> is compiled from <CODE>build/world/world.c</CODE>, and <CODE>export/include/world.h</CODE> is installed from <CODE>build/world/world.h</CODE>. This is accomplished on most systems by the simple expedient of ``hard''
linking the required files from each source directory into the appropriate
build directory.


<P>

The links are maintained correctly by Cons, no matter what you do to the
source directory. If you modify a source file, your editor may do this ``in
place'' or it may rename it first and create a new file. In the latter
case, any hard link will be lost. Cons will detect this condition the next
time the source file is needed, and will relink it appropriately.


<P>

You'll also notice, by the way, that <STRONG>no</STRONG> changes were required to the underlying <CODE>Conscript</CODE> files. And we can go further, as we shall see in the next section.


<P>

<H1><A NAME="B_Variant_builds_"><STRONG>Variant builds</STRONG>

</A></H1>
<DT><STRONG>Hello, World! for baNaNa and peAcH OS's

</A></STRONG><DD>
Variant builds require just another simple extension. Let's take as an
example a requirement to allow builds for both the baNaNa and peAcH
operating systems. In this case, we are using a distributed file system,
such as NFS to access the particular system, and only one or the other of
the systems has to be compiled for any given invocation of <CODE>cons</CODE>. Here's one way we could set up the <CODE>Construct</CODE> file for our <STRONG>Hello, World!</STRONG> application:


<P>

<PRE>  # Construct file for Hello, World!
  
  die qq(OS must be specified) unless $OS = $ARG{OS};
  die qq(OS must be &quot;peach&quot; or &quot;banana&quot;)
        if $OS ne &quot;peach&quot; &amp;&amp; $OS ne &quot;banana&quot;;
</PRE>

<P>

<PRE>  # Where to put all our shared products.
  $EXPORT = &quot;#export/$OS&quot;;
  
  Export qw( CONS INCLUDE LIB BIN );
  
  # Standard directories for sharing products.
  $INCLUDE = &quot;$EXPORT/include&quot;;
  $LIB = &quot;$EXPORT/lib&quot;;
  $BIN = &quot;$EXPORT/bin&quot;;
  
  # A standard construction environment.
  $CONS = new cons (
        CPPPATH =&gt; $INCLUDE,                    # Include path for C Compilations
        LIBPATH =&gt; $LIB         ,       # Library path for linking programs
        LIBS =&gt; '-lworld',                      # List of standard libraries
  );
</PRE>

<P>

<PRE>  # $BUILD is where we will derive everything.
  $BUILD = &quot;#build/$OS&quot;;
</PRE>

<P>

<PRE>  # Tell cons where the source files for $BUILD are.
  Link $BUILD =&gt; 'src';
  
  Build (
        &quot;$BUILD/hello/Conscript&quot;,
        &quot;$BUILD/world/Conscript&quot;,
  );
</PRE>

<P>

Now if we login to a peAcH system, we can build our <STRONG>Hello, World!</STRONG> application for that platform:


<P>

<PRE>  % cons export OS=peach
  Install build/peach/world/world.h as export/peach/include/world.h
  cc -Iexport/peach/include -c build/peach/hello/hello.c -o build/peach/hello/hello.o
  cc -Iexport/peach/include -c build/peach/world/world.c -o build/peach/world/world.o
  ar r build/peach/world/libworld.a build/peach/world/world.o
  ar: creating build/peach/world/libworld.a
  ranlib build/peach/world/libworld.a
  Install build/peach/world/libworld.a as export/peach/lib/libworld.a
  cc -o build/peach/hello/hello build/peach/hello/hello.o -Lexport/peach/lib -lworld
  Install build/peach/hello/hello as export/peach/bin/hello
</PRE>

<P>

<DT><STRONG><A NAME="item_Variations">Variations on a theme

</A></STRONG><DD>
Other variations of this model are possible. For example, you might decide
that you want to separate out your include files into platform dependent
and platform independent files. In this case, you'd have to define an
alternative to <CODE>$INCLUDE</CODE> for platform-dependent files. Most <CODE>Conscript</CODE> files, generating purely platform-independent include files, would not have
to change.


<P>

You might also want to be able to compile your whole system with debugging
or profiling, for example, enabled. You could do this with appropriate
command line options, such as <CODE>DEBUG=on</CODE>. This would then be translated into the appropriate platform-specific
requirements to enable debugging (this might include turning off
optimization, for example). You could optionally vary the name space for
these different types of systems, but, as we'll see in the next section,
it's not <STRONG>essential</STRONG> to do this, since Cons is pretty smart about rebuilding things when you
change options.


<P>

<H1><A NAME="B_Signatures_"><STRONG>Signatures</STRONG>

</A></H1>
<DT><STRONG><A NAME="item_MD5">MD5 cryptographic signatures

</A></STRONG><DD>
Whenever Cons creates a derived file, it stores a <STRONG>signature</STRONG> for that file. The signature is stored in a separate file, one per
directory. After the previous example was compiled, the <CODE>.consign</CODE> file in the <CODE>build/peach/world</CODE> directory looked like this:


<P>

<PRE>  world.o:834179303 23844c0b102ecdc0b4548d1cd1cbd8c6
  libworld.a:834179304 9bf6587fa06ec49d864811a105222c00
</PRE>

<P>

The first number is a timestamp--for a UNIX systems, this is typically the
number of seconds since January 1st, 1970. The second value is an MD5
checksum. The <STRONG>Message Digest Algorithm</STRONG> is an algorithm that, given an input string, computes a strong
cryptographic signature for that string. The MD5 checksum stored in the <CODE>.consign</CODE> file is, in effect, a digest of all the dependency information for the
specified file. So, for example, for the file <CODE>world.o</CODE>, this includes at least the file <CODE>world.c</CODE>, and also any header files that Cons knows about that are included,
directly or indirectly by <CODE>world.c</CODE>. Not only that, but the actual command line that was used to generate <CODE>world.o</CODE> is also fed into the computation of the signature. Similarly, <CODE>libworld.a</CODE> gets a signature which ``includes'' all the signatures of its constituents
(and hence, transitively, the signatures of <STRONG>their</STRONG> constituents), as well as the command line that created the file.


<P>

The signature of a non-derived file is computed, by default, by taking the
current modification time of the file and the file's entry name (unless
there happens to be a current <CODE>.consign</CODE> entry for that file, in which case that signature is used).


<P>

Notice that there is no need for a derived file to depend upon any
particular <CODE>Construct</CODE> or <CODE>Conscript</CODE> file--if changes to these files affect the file in question, then this will
be automatically reflected in its signature, since relevant parts of the
command line are included in the signature. Unrelated changes will have no
effect.


<P>

When Cons considers whether to derive a particular file, then, it first
computes the expected signature of the file. It then compares the file's
last modification time with the time recorded in the <CODE>.consign</CODE> entry, if one exists. If these times match, then the signature stored in
the <CODE>.consign</CODE> file is considered to be accurate. If the file's previous signature does
not match the new, expected signature, then the file must be rederived.


<P>

Notice that a file will be rederived whenever anything about a dependent
file changes. In particular, notice that <STRONG>any</STRONG> change to the modification time of a dependent (forward or backwards in
time) will force recompilation of the derived file.


<P>

The use of these signatures is an extremely simple, efficient, and
effective method of improving--dramatically--the reproducibility of a
system.


<P>

We'll demonstrate this with a simple example:


<P>

<PRE>  # Simple &quot;Hello, World!&quot; Construct file
  $CFLAGS = '-g' if $ARG{DEBUG} eq 'on';
  $CONS = new cons(CFLAGS =&gt; $CFLAGS);
  Program $CONS 'hello', 'hello.c';
</PRE>

<P>

Notice how Cons recompiles at the appropriate times:


<P>

<PRE>  % cons hello
  cc -c hello.c -o hello.o
  cc -o hello hello.o
  % cons hello
  cons: &quot;hello&quot; is up-to-date.
  % cons DEBUG=on hello
  cc -g -c hello.c -o hello.o
  cc -o hello hello.o
  % cons DEBUG=on hello
  cons: &quot;hello&quot; is up-to-date.
  % cons hello
  cc -c hello.c -o hello.o
  cc -o hello hello.o
</PRE>

<P>

<H1><A NAME="B_Code_Repositories_"><STRONG>Code Repositories</STRONG>

</A></H1>
Many software development organizations will have one or more central
repository directory trees containing the current source code for one or
more projects, as well as the derived object files, libraries, and
executables. In order to reduce unnecessary recompilation, it is useful to
use files from the repository to build development software--assuming, of
course, that no newer dependency file exists in the local build tree.


<P>

<DT><STRONG><A NAME="item_Repository">Repository

</A></STRONG><DD>
Cons provides a mechanism to specify a list of code repositories that will
be searched, in-order, for source files and derived files not found in the
local build directory tree.


<P>

The following lines in a <CODE>Construct</CODE> file will instruct Cons to look first under the
<CODE>/usr/experiment/repository</CODE> directory and then under the <CODE>/usr/product/repository</CODE> directory:


<P>

<PRE>  Repository qw (
        /usr/experiment/repository
        /usr/product/repository
  );
</PRE>

<P>

The repository directories specified may contain source files, derived
files (objects, libraries and executables), or both. If there is no local
file (source or derived) under the directory in which Cons is executed,
then the first copy of a same-named file found under a repository directory
will be used to build any local derived files.


<P>

Cons maintains one global list of repositories directories. Cons will
eliminate the current directory, and any non-existent directories, from the
list.


<P>

<DT><STRONG><A NAME="item_Finding">Finding the Construct file in a Repository

</A></STRONG><DD>
Cons will also search for <CODE>Construct</CODE> and <CODE>Conscript</CODE> files in the repository tree or trees. This leads to a chicken-and-egg
situation, though: how do you look in a repository tree for a <CODE>Construct</CODE> file if the <CODE>Construct</CODE> file tells you where the repository is? To get around this, repositories
may be specified via
<CODE>-R</CODE> options on the command line:


<P>

<PRE>  % cons -R /usr/experiment/repository -R /usr/product/repository .
</PRE>

<P>

Any repository directories specified in the <CODE>Construct</CODE>
or <CODE>Conscript</CODE> files will be appended to the repository directories specified by
command-line <CODE>-R</CODE> options.


<P>

<DT><STRONG>Repository source files

</A></STRONG><DD>
If the source code (include the <CODE>Conscript</CODE> file) for the library version of the <EM>Hello, World!</EM> C application is in a repository (with no derived files), Cons will use the
repository source files to create the local object files and executable
file:


<P>

<PRE>  % cons -R /usr/src_only/repository hello
  gcc -c /usr/src_only/repository/hello.c -o hello.o
  gcc -c /usr/src_only/repository/world.c -o world.o
  ar r libworld.a world.o
  ar: creating libworld.a
  ranlib libworld.a
  gcc -o hello hello.o libworld.a
</PRE>

<P>

Creating a local source file will cause Cons to rebuild the appropriate
derived file or files:


<P>

<PRE>  % touch world.c
  % cons -R /usr/src_only/repository hello
  gcc -c world.c -o world.o
  ar r libworld.a world.o
  ar: creating libworld.a
  ranlib libworld.a
  gcc -o hello hello.o libworld.a
</PRE>

<P>

And removing the local source file will cause Cons to revert back to
building the derived files from the repository source:


<P>

<PRE>  % touch -R /usr/src_only/repository hello world.c
  % cons hello
  gcc -c /usr/src_only/world.c/repository -o world.o
  ar r libworld.a world.o
  ar: creating libworld.a
  ranlib libworld.a
  gcc -o hello hello.o libworld.a
</PRE>

<P>

<DT><STRONG>Repository derived files

</A></STRONG><DD>
If a repository tree contains derived files (usually object files,
libraries, or executables), Cons will perform its normal signature
calculation to decide whether the repository file is up-to-date or a
derived file must be built locally. This means that, in order to ensure
correct signature calculation, a repository tree must also contain the <CODE>.consign</CODE> files that were created by Cons when generating the derived files.


<P>

This would usually be accomplished by building the software in the
repository (or, alternatively, in a build directory, and then copying the
result to the repository):


<P>

<PRE>  % cd /usr/all/repository
  % cons hello
  gcc -c hello.c -o hello.o
  gcc -c world.c -o world.o
  ar r libworld.a world.o
  ar: creating libworld.a
  ranlib libworld.a
  gcc -o hello hello.o libworld.a
</PRE>

<P>

(This is safe even if the <CODE>Construct</CODE> file lists the <CODE>/usr/all/repository</CODE> directory in a <A HREF="#item_Repository">Repository</A> command because Cons will remove the current directory from the repository
list.)


<P>

Now if we want to build a copy of the application with our own <CODE>hello.c</CODE> file, we only need to create the one necessary source file, and use the <CODE>-R</CODE> option to have Cons use other files from the repository:


<P>

<PRE>  % mkdir $HOME/build1
  % cd $HOME/build1
  % touch hello.c
  % cons -R /usr/all/repository hello
  gcc -c hello.c -o hello.o
  gcc -o hello hello.o /usr/all/repository/libworld.a
</PRE>

<P>

Notice that Cons has not bothered to recreate a local <CODE>libworld.a</CODE> library (or recompile the <CODE>world.o</CODE> module), but instead uses the already-compiled version from the repository.


<P>

Because the MD5 signatures that Cons puts in the <CODE>.consign</CODE> file contain timestamps for the derived files, the signature timestamps
must match the file timestamps for a signature to be considered valid.


<P>

Some software systems may alter the timestamps on repository files (by
copying them, e.g.), in which case Cons will, by default, assume the
repository signatures are invalid and rebuild files unnecessarily. This
behavior may be altered by specifying:


<P>

<PRE>  Repository_Sig_Times_OK 0;
</PRE>

<P>

This tells Cons to ignore timestamps when deciding whether a signature is
valid. (Note that avoiding this sanity check means there must be proper
control over the repository tree to ensure that the derived files cannot be
modified without updating the <CODE>.consign</CODE> signature.)


<P>

<DT><STRONG><A NAME="item_Local">Local copies of files

</A></STRONG><DD>
If the repository tree contains the complete results of a build, and we try
to build from the repository without any files in our local tree, something
moderately surprising happens:


<P>

<PRE>  % mkdir $HOME/build2
  % cd $HOME/build2
  % cons -R /usr/all/repository hello
  cons: &quot;hello&quot; is up-to-date.
</PRE>

<P>

Why does Cons say that the <CODE>hello</CODE> program is up-to-date when there is no <CODE>hello</CODE> program in the local build directory? Because the repository (not the local
directory) contains the up-to-date <CODE>hello</CODE> program, and Cons correctly determines that nothing needs to be done to
rebuild this up-to-date copy of the file.


<P>

There are, however, many times in which it is appropriate to ensure that a
local copy of a file always exists. A packaging or testing script, for
example, may assume that certain generated files exist locally Instead of
making these subsidiary scripts aware of the repository directory, the <A HREF="#item_Local">Local</A> command may be added to a <CODE>Construct</CODE> or <CODE>Conscript</CODE> file to specify that a certain file or files must appear in the local build
directory:


<P>

<PRE>  Local qw(
        hello
  );
</PRE>

<P>

Then, if we re-run the same command, Cons will make a local copy of the
program from the repository copy (telling you that it is doing so):


<P>

<PRE>  % cons -R /usr/all/repository hello
  Local copy of hello from /usr/all/repository/hello
  cons: &quot;hello&quot; is up-to-date.
</PRE>

<P>

Notice that, because the act of making the local copy is not considered a
``build'' of the <CODE>hello</CODE> file, Cons still reports that it is up-to-date.


<P>

Creating local copies is most useful for files that are being installed
into an intermediate directory (for sharing with other directories) via the <CODE>Install</CODE> command. Accompanying the <CODE>Install</CODE> command for a file with a companion <A HREF="#item_Local">Local</A> command is so common that Cons provides a
<CODE>Install_Local</CODE> command as a convenient way to do both:


<P>

<PRE>  Install_Local $env, '#export', 'hello';
</PRE>

<P>

is exactly equivalent to:


<P>

<PRE>  Install $env '#export', 'hello';
  Local '#export/hello';
</PRE>

<P>

Both the <A HREF="#item_Local">Local</A> and <CODE>Install_Local</CODE> commands update the local
<CODE>.consign</CODE> file with the appropriate file signatures, so that future builds are
performed correctly.


<P>

<DT><STRONG>Repository dependency analysis

</A></STRONG><DD>
Due to its built-in scanning, Cons will search the specified repository
trees for included <CODE>.h</CODE> files. Unless the compiler also knows about the repository trees, though,
it will be unable to find <CODE>.h</CODE> files that only exist in a repository. If, for example, the <CODE>hello.c</CODE> file includes the <CODE>hello.h</CODE> file in its current directory:


<P>

<PRE>  % cons -R /usr/all/repository hello
  gcc -c /usr/all/repository/hello.c -o hello.o
  /usr/all/repository/hello.c:1: hello.h: No such file or directory
</PRE>

<P>

Solving this problem forces some requirements onto the way construction
environments are defined and onto the way the C <CODE>#include</CODE> preprocessor directive is used to include files.


<P>

In order to inform the compiler about the repository trees, Cons will add
appropriate <CODE>-I</CODE> flags to the compilation commands. This means that the <CODE>CPPPATH</CODE> variable in the construct environment must explicitly specify all
subdirectories which are to be searched for included files, including the
current directory. Consequently, we can fix the above example by changing
the environment creation in the <CODE>Construct</CODE> file as follows:


<P>

<PRE>  $env = new cons(
        CC      =&gt; 'gcc',
        CPPPATH =&gt; '.',
        LIBS    =&gt; 'libworld.a',
  );
</PRE>

<P>

Due to the definition of the <CODE>CPPPATH</CODE> variable, this yields, when we re-execute the command:


<P>

<PRE>  % cons -R /usr/all/repository hello
  gcc -c -I. -I/usr/all/repository /usr/all/repository/hello.c -o hello.o
  gcc -o hello hello.o /usr/all/repository/libworld.a
</PRE>

<P>

The order of the <CODE>-I</CODE> flags replicates, for the C preprocessor, the same repository-directory
search path that Cons uses for its own dependency analysis. If there are
multiple repositories and multiple <CODE>CPPPATH</CODE> directories, Cons will append the repository directories to the beginning
of each <CODE>CPPPATH</CODE> directory, rapidly multiplying the number of <CODE>-I</CODE> flags. As an extreme example, a <CODE>Construct</CODE> file containing:


<P>

<PRE>  Repository qw(
        /u1
        /u2
  );
</PRE>

<P>

<PRE>  $env = new cons(
        CPPPATH =&gt; 'a:b:c',
  );
</PRE>

<P>

Would yield a compilation command of:


<P>

<PRE>        cc -Ia -I/u1/a -I/u2/a -Ib -I/u1/b -I/u2/b -Ic -I/u1/c -I/u2/c -c hello.c -o hello.o
</PRE>

<P>

Because Cons relies on the compiler's <CODE>-I</CODE> flags to communicate the order in which repository directories must be
searched, Cons' handling of repository directories is fundamentally
incompatible with using double-quotes on the <CODE>#include</CODE> directives in your C source code:


<P>

<PRE>  #include &quot;file.h&quot;     /* DON'T USE DOUBLE-QUOTES LIKE THIS */
</PRE>

<P>

This is because most C preprocessors, when faced with such a directive,
will always first search the directory containing the source file. This
undermines the elaborate <CODE>-I</CODE> options that Cons constructs to make the preprocessor conform to its
preferred search path.


<P>

Consequently, when using repository trees in Cons,
<STRONG>always</STRONG> use angle-brackets for included files:


<P>

<PRE>  #include &lt;file.h&gt;     /* USE ANGLE-BRACKETS INSTEAD */
</PRE>

<P>

<DT><STRONG><A NAME="item_Repository_List">Repository_List

</A></STRONG><DD>
Cons provides a <A HREF="#item_Repository_List">Repository_List</A> command to return a list of all repository directories in their current
search order. This can be used for debugging, or to do more complex Perl
stuff:


<P>

<PRE>  @list = Repository_List;
  print join(' ', @list), &quot;\n&quot;;
</PRE>

<P>

<DT><STRONG>Repository interaction with other Cons features

</A></STRONG><DD>
Cons' handling of repository trees interacts correctly with other Cons
features--which is to say, it generally does what you would expect.


<P>

Most notably, repository trees interact correctly, and rather powerfully,
with the 'Link' command. A repository tree may contain one or more
subdirectories for version builds established via <CODE>Link</CODE> to a source subdirectory. Cons will search for derived files in the
appropriate build subdirectories under the repository tree.


<P>

<H1><A NAME="B_Selective_builds_"><STRONG>Selective builds</STRONG>

</A></H1>
Cons provides two methods for reducing the size of given build. The first
is by specifying targets on the command line, and the second is a method
for pruning the build tree. We'll consider target specification first.


<P>

<DT><STRONG><A NAME="item_Selective">Selective targeting

</A></STRONG><DD>
Like make, Cons allows the specification of ``targets'' on the command
line. Cons targets may be either files or directories. When a directory is
specified, this is simply a short-hand notation for every derivable
product--that Cons knows about--in the specified directory and below. For
example:


<P>

<PRE>  cons build/hello/hello.o
</PRE>

<P>

means build<CODE>hello.o</CODE> and everything that <CODE>hello.o</CODE> might need. This is from a previous version of the <STRONG>Hello, World!</STRONG> program in which <CODE>hello.o</CODE> depended upon <CODE>export/include/world.h</CODE>. If that file is not up-to-date (because someone modified <CODE>src/world/world.h)</CODE>, then it will be rebuilt, even though it is in a directory remote from <CODE>build/hello</CODE>.


<P>

In this example:


<P>

<PRE>  cons build
</PRE>

<P>

Everything in the <CODE>build</CODE> directory is built, if necessary. Again, this may cause more files to be
built. In particular, both <CODE>export/include/world.h</CODE> and <CODE>export/lib/libworld.a</CODE> are required by the <CODE>build/hello</CODE> directory, and so they will be built if they are out-of-date.


<P>

If we do, instead:


<P>

<PRE>  cons export
</PRE>

<P>

then only the files that should be installed in the export directory will
be rebuilt, if necessary, and then installed there. Note that <CODE>cons build</CODE> might build files that <CODE>cons export</CODE> doesn't build, and <STRONG>vice-versa</STRONG>.


<P>

<DT><STRONG><A NAME="item_No">No ``special'' targets

</A></STRONG><DD>
With Cons, make-style ``special'' targets are not required. The simplest
analog with Cons is to use special <CODE>export</CODE> directories, instead. Let's suppose, for example, that you have a whole
series of unit tests that are associated with your code. The tests live in
the source directory near the code. Normally, however, you don't want to
build these tests. One solution is to provide all the build instructions
for creating the tests, and then to install the tests into a separate part
of the tree. If we install the tests in a top-level directory called <CODE>tests</CODE>, then:


<P>

<PRE>  cons tests
</PRE>

<P>

will build all the tests.


<P>

<PRE>  cons export
</PRE>

<P>

will build the production version of the system (but not the tests), and:


<P>

<PRE>  cons build
</PRE>

<P>

should probably be avoided (since it will compile tests unecessarily).


<P>

If you want to build just a single test, then you could explicitly name the
test (in either the <CODE>tests</CODE> directory or the <CODE>build</CODE> directory). You could also aggregate the tests into a convenient hierarchy
within the tests directory. This hierarchy need not necessarily match the
source hierarchy, in much the same manner that the include hierarchy
probably doesn't match the source hierarchy (the include hierarchy is
unlikely to be more than two levels deep, for C programs).


<P>

If you want to build absolutely everything in the tree (subject to whatever
options you select), you can use:


<P>

<PRE>  cons .
</PRE>

<P>

This is not particularly efficient, since it will redundantly walk all the
trees, including the source tree. The source tree, of course, may have
buildable objects in it--nothing stops you from doing this, even if you
normally build in a separate build tree.


<P>

<H1><A NAME="B_Build_Pruning_"><STRONG>Build Pruning</STRONG>

</A></H1>
In conjunction with target selection, <STRONG>build pruning</STRONG> can be used to reduce the scope of the build. In the previous peAcH and
baNaNa example, we have already seen how script-driven build pruning can be
used to make only half of the potential build available for any given
invocation of <CODE>cons</CODE>. Cons also provides, as a convenience, a command line convention that
allows you to specify which <CODE>Conscript</CODE> files actually get ``built''--that is, incorporated into the build tree.
For example:


<P>

<PRE>  cons build +world
</PRE>

<P>

The <CODE>+</CODE> argument introduces a Perl regular expression. This must, of course, be
quoted at the shell level if there are any shell meta-characters within the
expression. The expression is matched against each <CODE>Conscript</CODE> file which has been mentioned in a <A HREF="#item_Build">Build</A> statement, and only those scripts with matching names are actually
incorporated into the build tree. Multiple such arguments are allowed, in
which case a match against any of them is sufficient to cause a script to
be included.


<P>

In the example, above, the <CODE>hello</CODE> program will not be built, since Cons will have no knowledge of the script <CODE>hello/Conscript</CODE>. The <CODE>libworld.a</CODE> archive will be built, however, if need be.


<P>

There are a couple of uses for build pruning via the command line. Perhaps
the most useful is the ability to make local changes, and then, with
sufficient knowledge of the consequences of those changes, restrict the
size of the build tree in order to speed up the rebuild time. A second use
for build pruning is to actively prevent the recompilation of certain files
that you know will recompile due to, for example, a modified header file.
You may know that either the changes to the header file are immaterial, or
that the changes may be safely ignored for most of the tree, for testing
purposes.With Cons, the view is that it is pragmatic to admit this type of
behavior, with the understanding that on the next full build everything
that needs to be rebuilt will be. There is no equivalent to a ``make
touch'' command, to mark files as permanently up-to-date. So any risk that
is incurred by build pruning is mitigated. For release quality work,
obviously, we recommend that you do not use build pruning (it's perfectly
OK to use during integration, however, for checking compilation, etc. Just
be sure to do an unconstrained build before committing the integration).


<P>

<H1><A NAME="B_Backing_builds_"><STRONG>Backing builds</STRONG>

</A></H1>
T.B.S.


<P>

<H1><A NAME="B_Temporary_overrides_"><STRONG>Temporary overrides</STRONG>

</A></H1>
Cons provides a very simple mechanism for overriding aspects of a build.
The essence is that you write an override file containing one or more <CODE>Override</CODE> commands, and you specify this on the command line, when you run <CODE>cons</CODE>:


<P>

<PRE>  cons -o over export
</PRE>

<P>

will build the <CODE>export</CODE> directory, with all derived files subject to the overrides present in the
file <CODE>over</CODE>. If you leave out the <CODE>-o</CODE> option, then everything necessary to remove all overrides will be rebuilt.


<P>

<DT><STRONG><A NAME="item_Overriding">Overriding environment variables

</A></STRONG><DD>
The override file can contain two types of overrides. The first is incoming
environment variables. These are normally accessible by the <CODE>Construct</CODE> file from the <CODE>%ENV</CODE> hash variable. These can trivially be overridden in the override file by
setting the appropriate elements of <CODE>%ENV</CODE> (these could also be overridden in the user's environment, of course).


<P>

<DT><STRONG>The Override command

</A></STRONG><DD>
The second type of override is accomplished with the <CODE>Override</CODE> command, which looks like this:


<P>

<PRE>  Override &lt;regexp&gt;, &lt;var1&gt; =&gt; &lt;value1&gt;, &lt;var2&gt; =&gt; &lt;value2&gt;, ...;
</PRE>

<P>

The regular expression <EM>regexp</EM> is matched against every derived file that is a candidate for the build. If
the derived file matches, then the variable/value pairs are used to
override the values in the construction environment associated with the
derived file.


<P>

Let's suppose that we have a construction environment like this:


<P>

<PRE>  $CONS = new cons(
        COPT =&gt; '',
        CDBG =&gt; '-g',
        CFLAGS =&gt; '%COPT %CDBG',
  );
</PRE>

<P>

Then if we have an override file <CODE>over</CODE> containing this command:


<P>

<PRE>  Override '\.o$', COPT =&gt; '-O', CDBG =&gt; '';
</PRE>

<P>

then any <CODE>cons</CODE> invocation with <CODE>-o over</CODE> that creates <CODE>.o</CODE> files via this environment will cause them to be compiled with <CODE>-O </CODE>and no <CODE>-g</CODE>. The override could, of course, be restricted to a single directory by the
appropriate selection of a regular expression.


<P>

Here's the original version of the Hello, World! program, built with this
environment. Note that Cons rebuilds the appropriate pieces when the
override is applied or removed:


<P>

<PRE>  % cons hello
  cc -g -c hello.c -o hello.o
  cc -o hello hello.o
  % cons -o over hello
  cc -O -c hello.c -o hello.o
  cc -o hello hello.o
  % cons -o over hello
  cons: &quot;hello&quot; is up-to-date.
  % cons hello
  cc -g -c hello.c -o hello.o
  cc -o hello hello.o
</PRE>

<P>

It's important that the <CODE>Override</CODE> command only be used for temporary, on-the-fly overrides necessary for
development because the overrides are not platform independent and because
they rely too much on intimate knowledge of the workings of the scripts.
For temporary use, however, they are exactly what you want.


<P>

Note that it is still useful to provide, say, the ability to create a fully
optimized version of a system for production use--from the <CODE>Construct</CODE> and <CODE>Conscript</CODE> files. This way you can tailor the optimized system to the platform. Where
optimizer trade-offs need to be made (particular files may not be compiled
with full optimization, for example), then these can be recorded for
posterity (and reproducibility) directly in the scripts.


<P>

<H1><A NAME="B_More_on_construction_environme"><STRONG>More on construction environments:Default construction variables</STRONG>

</A></H1>
We have mentioned, and used, the concept of a <STRONG>construction environment</STRONG>, many times in the preceding pages. Now it's time to make this a little
more concrete. With the following statement:


<P>

<PRE>  $env = new cons();
</PRE>

<P>

<DT><STRONG><A NAME="item_Default">Default construction variables

</A></STRONG><DD>
a reference to a new, default construction environment is created. This
contains a number of construction variables and some methods. At the
present writing, the default list of construction variables is defined as
follows:


<P>

<PRE>  CC    =&gt; 'cc',
  CFLAGS        =&gt; '',
  CCCOM =&gt; '%CC %CFLAGS %_IFLAGS -c %&lt; -o %&gt;',
  CPPPATH       =&gt; '',
  LINK  =&gt; '%CC',                   
  LINKCOM       =&gt; '%LINK %LDFLAGS -o %&gt; %&lt; %_LDIRS %LIBS',
  LIBPATH       =&gt; '',
  LIBS  =&gt; '',
  AR    =&gt; 'ar',
  ARCOM =&gt; &quot;%AR %ARFLAGS %&gt; %&lt;\n%RANLIB %&gt;&quot;,
  ARFLAGS       =&gt; 'r',
  RANLIB        =&gt; 'ranlib',            
  AS    =&gt; 'as',
  ASFLAGS       =&gt; '',
  ASCOM =&gt; '%AS %ASFLAGS %&lt; -o %&gt;',
  LD    =&gt; 'ld',        
  LDFLAGS       =&gt; '',
  SUFLIB        =&gt; '.a',
  SUFOBJ        =&gt; '.o',
  ENV   =&gt; { PATH =&gt; '/bin:/usr/bin' },
</PRE>

<P>

These variables are used by the various methods associated with the
environment, in particular any method that ultimately invokes an external
command will substitute these variables into the final command, as
appropriate. For example, the <CODE>Objects</CODE> method takes a number of source files and arranges to derive, if necessary,
the corresponding object files. For example:


<P>

<PRE>  Objects $env 'foo.c', 'bar.c';
</PRE>

<P>

This will arrange to produce, if necessary, <CODE>foo.o</CODE> and <CODE>bar.o</CODE>. The command invoked is simply <CODE>%CCOM</CODE>, which expands through substitution, to the appropriate external command
required to build each object. We will explore the substitution rules
further under the <CODE>Command</CODE> method, below.


<P>

The construction variables are also used for other purposes. For example, <CODE>CPPPATH</CODE> is used to specify a colon-separated path of include directories. These are
intended to be passed to the C preprocessor and are also used by the C-file
scanning machinery to determine the dependencies involved in a C
Compilation. Variables beginning with underscore, are created by various
methods, and should normally be considered ``internal'' variables. For
example, when a method is called which calls for the creation of an object
from a C source, the variable <CODE>_IFLAGS</CODE> is created: this corresponds to the <CODE>-I</CODE> switches required by the C compiler to represent the directories specified
by <CODE>CPPPATH</CODE>.


<P>

Note that, for any particular environment, the value of a variable is set
once, and then never reset (to change a variable, you must create a new
environment. Methods are provided for copying existing environments for
this purpose). Some internal variables, such as <CODE>_IFLAGS</CODE> are created on demand, but once set, they remain fixed for the life of the
environment.


<P>

Another variable, <CODE>ENV</CODE>, is used to determine the system environment during the execution of an
external command. By default, the only environment variable that is set is <CODE>PATH</CODE>, which is the execution path for a UNIX command. For the utmost
reproducibility, you should really arrange to set your own execution path,
in your top-level <CODE>Construct</CODE> file (or perhaps by importing an appropriate construction package with the
Perl <CODE>use</CODE> command). The default variables are intended to get you off the ground.


<P>

<H1><A NAME="B_Default_construction_methods_"><STRONG>Default construction methods</STRONG>

</A></H1>
The list of default construction methods includes the following:


<P>

<DT><STRONG>The new constructor

</A></STRONG><DD>
The <CODE>new</CODE> method is a Perl object constructor. That is, it is not invoked via a
reference to an existing construction environment <STRONG>reference</STRONG>, but, rather statically, using the name of the Perl <STRONG>package</STRONG> where the constructor is defined. The method is invoked like this:


<P>

<PRE>  $env = new cons(&lt;overrides&gt;);
</PRE>

<P>

The environment you get back is blessed into the package <CODE>cons</CODE>, which means that it will have associated with it the default methods
described below. Individual construction variables can be overridden by
providing name/value pairs in an override list. Note that to override any
command environment variable (i.e. anything under <CODE>ENV</CODE>), you will have to override all of them. You can get around this
difficulty by using the <CODE>copy</CODE> method on an existing construction environment.


<P>

<DT><STRONG>The clone method

</A></STRONG><DD>
The <CODE>clone</CODE> method creates a clone of an existing construction environment, and can be
called as in the following example:


<P>

<PRE>  $env2 = $env1-&gt;clone(&lt;overrides&gt;);
</PRE>

<P>

You can provide overrides in the usual manner to create a different
environment from the original. If you just want a new name for the same
environment (which may be helpful when exporting environments to existing
components), you can just use simple assignment.


<P>

<DT><STRONG>The copy method

</A></STRONG><DD>
The <CODE>copy</CODE> method extracts the externally defined construction variables from an
environment and returns them as a list of name/value pairs. Overrides can
also be provided, in which case, the overridden values will be returned, as
appropriate. The returned list can be assigned to a hash, as shown in the
prototype, below, but it can also be manipulated in other ways: 


<P>

<PRE>  %env = $env1-&gt;copy(&lt;overrides&gt;);
</PRE>

<P>

The value of <CODE>ENV</CODE>, which is itself a hash, is also copied to a new hash, so this may be
changed without fear of affecting the original environment. So, for
example, if you really want to override just the <CODE>PATH</CODE> variable in the default environment, you could do the following:


<P>

<PRE>  %cons = new cons()-&gt;copy();
  $cons{ENV}{PATH} = &quot;&lt;your path here&gt;&quot;;
  $cons = new cons(%cons);
</PRE>

<P>

This will leave anything else that might be in the default execution
environment undisturbed.


<P>

<DT><STRONG>The Install method

</A></STRONG><DD>
The <CODE>Install</CODE> method arranges for the specified files to be installed in the specified
directory. The installation is optimized: the file is not copied if it can
be linked. If this is not the desired behavior, you will need to use a
different method to install the file. It is called as follows:


<P>

<PRE>  Install $env &lt;directory&gt;, &lt;names&gt;;
</PRE>

<P>

Note that, while the files to be installed may be arbitrarily named, only
the last component of each name is used for the installed target name. So,
for example, if you arrange to install <CODE>foo/bar</CODE> in <CODE>baz</CODE>, this will create a file <CODE>bar</CODE> in directory <CODE>baz</CODE> (not <CODE>foo/bar</CODE>).


<P>

<DT><STRONG>The Command method

</A></STRONG><DD>
The <CODE>Command</CODE> method is a catchall method which can be used to arrange for any external
command to be called to update the target. For this command, a target file
and list of inputs is provided. In addition a construction command line, or
lines, is provided as a string (this string may have multiple commands
embedded within it, separated by new lines). <CODE>Command</CODE> is called as follows:


<P>

<PRE>  Command $env &lt;target&gt;, &lt;inputs&gt;, &lt;construction command&gt;;
</PRE>

<P>

The target is made dependent upon the list of input files specified, and
the inputs must be built successfully or Cons will not attempt to build the
target.


<P>

Within the construction command, any variable from the construction
environment may be introduced by prefixing the name of the construction
variable with <CODE>%</CODE>. This is recursive: the command is expanded until no more substitutions
can be made. If a construction variable is not defined in the environment,
then the null string will be substituted.


<P>

There are several pseudo variables which will also be expanded:


<P>

<DL>
<DT><STRONG><A NAME="item__">%>

</A></STRONG><DD>
The target file name (in a multi-target command, this is always the first
target mentioned). 


<P>

<DT><STRONG><A NAME="item__0">%0

</A></STRONG><DD>
Same as <CODE>%</CODE>&gt;. 


<P>

<DT><STRONG><A NAME="item__1_">%1,

</A></STRONG><DD>
%2, ..., <CODE>%9</CODE> These refer to the first through ninth input file,
respectively. 


<P>

<DT><STRONG><A NAME="item_C">C<%<>

</A></STRONG><DD>
The full set of inputs. If any of these have been used anywhere else in the
current command line (via <CODE>%1</CODE>, <CODE>%2</CODE>, etc.), then those will be deleted from the list provided by <CODE>%<</CODE>. Consider the following command found in a <CODE>Conscript</CODE> file in the directory <CODE>test</CODE>: 


<P>

<PRE>  Command $env 'tgt', qw(foo bar baz), qq(
        echo %&lt; -i %1 &gt; %&gt;
        echo %&lt; -i %2 &gt;&gt; %&gt;
        echo %&lt; -i %3 &gt;&gt; %&gt;
  );
</PRE>

<P>

<DT><STRONG></STRONG><DD>
If <CODE>tgt</CODE> needed to be updated, then this would result in the execution of the
following commands, assuming that no remapping has been established for
directory <CODE>test</CODE>: 


<P>

<PRE>  echo test/bar test/baz -i test/foo &gt; test/tgt
  echo test/foo test/baz -i test/bar &gt;&gt; test/tgt
  echo test/foo test/bar -i test/baz &gt;&gt; test/tgt
</PRE>

<P>

</DL>
<PRE> Any of the above pseudo variables may be followed immediately by C&lt;:d&gt; or C&lt;:f&gt;, to indicate the directory or file associated with the name. Continuing with the above example, C&lt;%&lt;:f&gt; would expand to C&lt;foo bar baz&gt;, and C&lt;%&gt;:d&gt; would expand to C&lt;test&gt;.
</PRE>

<P>

After substitution occurs, strings of white space are converted into single
blanks, and leading and trailing white space is eliminated. It is therefore
not possible to introduce variable length white space in strings passed
into a command, without resorting to some sort of shell quoting.


<P>

If a multi-line command string is provided, the commands are executed
sequentially. If any of the commands fails, then none of the rest are
executed, and the target is not marked as updated, i.e. a new signature is
not stored for the target.


<P>

Normally, if all the commands succeed, and return a zero status (or
whatever platform-specific indication of success is required), then a new
signature is stored for the target. If a command erroneously reports
success even after a failure, then Cons will assume that the target file
created by that command is accurate and up-to-date.


<P>

The first word of each command string, after expansion, is assumed to be an
executable command looked up on the <CODE>PATH</CODE> environment variable (which is, in turn, specified by the <CODE>ENV</CODE> construction variable). If this command is found on the path, then the
target will depend upon it: the command will therefore be automatically
built, as necessary. It's possible to write multi-part commands to some
shells, separated by semi-colons. Only the first command word will be
depended upon, however, so if you write your command strings this way, you
must either explicitly set up a dependency (with the <CODE>Depends</CODE> method), or be sure that the command you are using is a system command
which is expected to be available. If it isn't available, you will, of
course, get an error.


<P>

If there are shell meta characters anywhere in the expanded command line,
such as <CODE><</CODE>, <CODE></CODE>&gt;, quotes, or semi-colon, then the command will actually be executed by
invoking a shell. This means that a command such as:


<P>

<PRE>  cd foo
</PRE>

<P>

alone will typically fail, since there is no command <CODE>cd</CODE> on the path. But the command string:


<P>

<PRE>  cd $&lt;:d; tar cf $&gt;:f $&lt;:f
</PRE>

<P>

when expanded will still contain the shell meta character semi-colon, and a
shell will be invoked to interpret the command. Since <CODE>cd</CODE> is interpreted by this sub-shell, the command will execute as expected.


<P>

To specify a command with multiple targets, you can specify a reference to
a list of targets. In Perl, a list reference can be created by enclosing a
list in square brackets. Hence the following command:


<P>

<PRE>  Command $env ['foo.h', 'foo.c'], 'foo.template', q(
        gen %1
  );
</PRE>

<P>

could be used in a case where the command <CODE>gen</CODE> creates two files, both <CODE>foo.h</CODE> and <CODE>foo.c</CODE>.


<P>

<DT><STRONG>The Objects method

</A></STRONG><DD>
The <CODE>Objects</CODE> method arranges to create the object files that correspond to the specified
source files. It is invoked as shown below:


<P>

<PRE>  @files = Objects $env &lt;source or object files&gt;;
</PRE>

<P>

Under Unix, source files ending in <CODE>.s</CODE> and <CODE>.c</CODE> are currently supported, and will be compiled into a name of the same file
ending in <CODE>.o</CODE>. By default, all files are created by invoking the external command which
results from expanding the <CODE>CCOM</CODE> construction variable, with <CODE>%<</CODE> and <CODE>%</CODE>&gt; set to the source and object files, respectively (see the <CODE>Command</CODE> method for expansion details) . The variable <CODE>CPPPATH</CODE> is also used when scanning source files for dependencies. This is a colon
separated list of pathnames, and is also used to create the construction
variable <CODE>_IFLAGS,</CODE> which will contain the appropriate list of -<CODE>I</CODE> options for the compilation. Any relative pathnames in <CODE>CPPPATH</CODE> is interpreted relative to the directory in which the associated
construction environment was created (absolute and top-relative names may
also be used). This variable is used by <CODE>CCOM</CODE>. The behavior of this command can be modified by changing any of the
variables which are interpolated into <CODE>CCOM</CODE>, such as <CODE>CC</CODE>, <CODE>CFLAGS</CODE>, and, indirectly, <CODE>CPPPATH</CODE>. It's also possible to replace the value of <CODE>CCOM</CODE>, itself. As a convenience, this file returns the list of object filenames.


<P>

<DT><STRONG>The Program method

</A></STRONG><DD>
The <CODE>Program</CODE> method arranges to link the specified program with the specified object
files. It is invoked in the following manner:


<P>

<PRE>  Program $env &lt;program name&gt;, &lt;source or object files&gt;;
</PRE>

<P>

Source files may be specified in place of objects files--the <CODE>Objects</CODE> method will be invoked to arrange the conversion of all the files into
object files, and hence all the observations about the <CODE>Objects</CODE> method, above, apply to this method also. The actual linking of the program
will be handled by an external command which results from expanding the <CODE>LINKCOM</CODE> construction variable, with <CODE>%<</CODE> set to the object files to be linked (in the order presented), and <CODE>%</CODE>&gt; set to the target (see the <CODE>Command</CODE> method for expansion details). The user may set additional variables in the
construction environment, including <CODE>LINK</CODE>, to define which program to use for linking, <CODE>LIBPATH</CODE>, a colon-separated list of library search paths, for use with library
specifications of the form <EM>-llib</EM>, and <CODE>LIBS</CODE>, specifying the list of libraries to link against (in either <EM>-llib</EM> form or just as pathnames. Relative pathnames in both <CODE>LIBPATH</CODE> and <CODE>LIBS</CODE> are interpreted relative to the directory in which the associated
construction environment created (absolute and top-relative names may also
be used). Cons automatically sets up dependencies on any libraries
mentioned in <CODE>LIBS</CODE>: those libraries will be built before the command is linked.


<P>

<DT><STRONG>The Library method

</A></STRONG><DD>
The <CODE>Library</CODE> method arranges to create the specified library from the specified object
files. It is invoked as follows:


<P>

<PRE>  Library $env &lt;library name&gt;, &lt;source or object files&gt;;
</PRE>

<P>

Source files may be specified in place of objects files--the <CODE>Objects</CODE> method will be invoked to arrange the conversion of all the files into
object files, and hence all the observations about the <CODE>Objects</CODE> method, above, apply to this method also. The actual creation of the
library will be handled by an external command which results from expanding
the <CODE>ARCOM</CODE> construction variable, with <CODE>%<</CODE> set to the library members (in the order presented), and <CODE>%</CODE>&gt; to the library to be created (see the <CODE>Command</CODE> method for expansion details). The user may set variables in the
construction environment which will affect the operation of the command.
These include <CODE>AR</CODE>, the archive program to use, <CODE>ARFLAGS</CODE>, which can be used to modify the flags given to the program specified by <CODE>AR</CODE>, and <CODE>RANLIB</CODE>, the name of a archive index generation program, if needed (if the
particular need does not require the latter functionality, then <CODE>ARCOM</CODE> must be redefined to not reference <CODE>RANLIB</CODE>).


<P>

The <CODE>Library</CODE> method allows the same library to be specified in multiple method
invocations. All of the contributing objects from all the invocations
(which may be from different directories) are combined and generated by a
single archive command. Note, however, that if you prune a build so that
only part of a library is specified, then only that part of the library
will be generated (the rest will disappear!).


<P>

<DT><STRONG>The Module method

</A></STRONG><DD>
The <CODE>Module</CODE> method is a combination of the <CODE>Program</CODE> and <CODE>Command</CODE> methods. Rather than generating an executable program directly, this
command allows you to specify your own command to actually generate a
module. The method is invoked as follows:


<P>

<PRE>  Module $env &lt;module name&gt;, &lt;source or object files&gt;, &lt;construction command&gt;;
</PRE>

<P>

This command is useful in instances where you wish to create, for example,
dynamically loaded modules, or statically linked code libraries. 


<P>

<DT><STRONG>The Depends method

</A></STRONG><DD>
The <CODE>Depends</CODE> method allows you to specify additional dependencies for a target. It is
invoked as follows:


<P>

<PRE>  Depends $env &lt;target&gt;, &lt;dependencies&gt;;
</PRE>

<P>

This may be occasionally useful, especially in cases where no scanner
exists (or is writable) for particular types of files. Normally,
dependencies are calculated automatically from a combination of the
explicit dependencies set up by the method invocation or by scanning source
files.


<P>

<H1><A NAME="B_Extending_Cons_"><STRONG>Extending Cons</STRONG>

</A></H1>
<DT><STRONG>Overriding construction variables

</A></STRONG><DD>
There are several ways of extending Cons, which vary in degree of
difficulty. The simplest method is to define your own construction
environment, based on the default environment, but modified to reflect your
particular needs. This will often suffice for C-based applications. You can
use the <CODE>new</CODE> constructor, and the <CODE>clone</CODE> and <CODE>copy</CODE> methods to create hybrid environments. These changes can be entirely
transparent to the underlying <CODE>Conscript</CODE> files.


<P>

<DT><STRONG><A NAME="item_Adding">Adding new methods

</A></STRONG><DD>
For slightly more demanding changes, you may wish to add new methods to the <CODE>cons</CODE> package. Here's an example of a very simple extension, <CODE>InstallScript</CODE>, which installs a tcl script in a requested location, but edits the script
first to reflect a platform-dependent path that needs to be installed in
the script:


<P>

<PRE>  # cons::InstallScript - Create a platform dependent version of a shell script
  # by replacing string ``#!your-path-here'' with platform specific path $BIN_DIR.
  sub cons::InstallScript {
        my($env, $dst, $src) = shift;
        Command $env $dst, $src, qq(
                sed s+your-path-here+$BINDIR+ %&lt; &gt; %&gt;
                chmod oug+x %&gt;
        );
  }
</PRE>

<P>

Notice that this method is defined directly in the <CODE>cons</CODE> package (by prefixing the name with <CODE>cons::</CODE>). A change made in this manner will be globally visible to all
environments, and could be called as in the following example:


<P>

<PRE>  InstallScript $env &quot;$BIN/foo&quot;, &quot;foo.tcl&quot;;
</PRE>

<P>

For a small improvement in generality, the <CODE>BINDIR</CODE> variable could be passed in as an argument or taken from the construction
environment--as <CODE>%BINDIR</CODE>.


<P>

<DT><STRONG>Overriding methods

</A></STRONG><DD>
Instead of adding the method to the <CODE>cons</CODE> name space, you could define a new package which inherits existing methods
from the <CODE>cons</CODE> package and overrides or adds others. This can be done using Perl's
inheritance mechanisms.


<P>

The following example defines a new package cons::switch which overrides
the standard <CODE>Library</CODE> method. The overridden method builds linked library modules, rather than
library archives. A new constructor is provided. Environments created with
this Constructor will have the new library method; others won't.


<P>

<PRE>  
</PRE>

<P>

<PRE>  package cons::switch;
  BEGIN {@ISA = `cons'}
</PRE>

<P>

<PRE>  sub new {
        shift;
        bless new cons(@_);
  }
</PRE>

<P>

<PRE>  sub Library {
        my($env) = shift;
        my($lib) = shift;
        my(@objs) = Objects $env @_;
        Command $env $lib, @objs, q(
                %LD -r %LDFLAGS %&lt; -o %&gt;
        );
  }
</PRE>

<P>

This functionality could be invoked as in the following example:


<P>

<PRE>  $env = new cons::switch(@overrides);
  ...
  Library $env 'lib.o', 'foo.c', 'bar.c';
</PRE>

<P>

<H1><A NAME="B_Invoking_Cons_"><STRONG>Invoking Cons</STRONG>

</A></H1>
The <CODE>cons</CODE> command is always invoked from the root of the build tree. A <CODE>Construct</CODE> file must exist in that directory. If the <CODE>-f</CODE> argument is used, then an alternate <CODE>Construct</CODE> file may be used (and, possibly, an alternate root, since <CODE>cons</CODE> will cd to <CODE>Construct</CODE> file's containing directory). The command is invoked as follows:


<P>

<PRE>  cons &lt;arguments&gt;
</PRE>

<P>

where <EM>arguments</EM> can be any of the following, in any order:


<P>

<DL>
<DT><STRONG><A NAME="item_target">target

</A></STRONG><DD>
Build the specified target. If <EM>target</EM> is a directory, then recursively build everything within that directory. 


<P>

<DT><STRONG><A NAME="item__pattern">+pattern

</A></STRONG><DD>
Limit the <CODE>Conscript </CODE>files considered to just those that match <EM>pattern</EM>, which is a Perl regular expression. Multiple <CODE>+</CODE> arguments are accepted. 


<P>

<DT><STRONG><A NAME="item_name">name=<val>

</A></STRONG><DD>
Sets <EM>name</EM> to value <EM>val</EM> in the <CODE>ARG</CODE> hash passed to the top-level <CODE>Construct</CODE> file. 


<P>

<DT><STRONG><A NAME="item__f">-f

</A></STRONG><DD>
&lt;file&gt; Use the specified file instead of <CODE>Construct</CODE> (but first change to containing directory of <EM>file</EM>). 


<P>

<DT><STRONG><A NAME="item__o">-o

</A></STRONG><DD>
&lt;file&gt; Read override file <EM>file</EM>. 


<P>

<DT><STRONG><A NAME="item__k">-k

</A></STRONG><DD>
Keep going as far as possible after errors. 


<P>

<DT><STRONG><A NAME="item__p">-p

</A></STRONG><DD>
Show construction products in specified trees. No build is attempted. 


<P>

<DT><STRONG><A NAME="item__pa">-pa

</A></STRONG><DD>
Show construction products and associated actions. No build is attempted. 


<P>

<DT><STRONG><A NAME="item__pw">-pw

</A></STRONG><DD>
Show products and where they are defined. No build is attempted. 


<P>

<DT><STRONG><A NAME="item__r">-r

</A></STRONG><DD>
Remove construction products associated with &lt;targets&gt;. No build is
attempted. 


<P>

<DT><STRONG><A NAME="item__v">-v

</A></STRONG><DD>
Show <CODE>cons</CODE> version and continue processing. 


<P>

<DT><STRONG><A NAME="item__x">-x

</A></STRONG><DD>
Show a help message similar to this one, and exit. 


<P>

</DL>
Note that<CODE>cons -r .</CODE> is equivalent to a full recursive <CODE>make clean</CODE>, but requires no support in the <CODE>Construct</CODE> file or any <CODE>Conscript</CODE> files. This is most useful if you are compiling files into source
directories (if you separate the <CODE>build</CODE>/<CODE>export</CODE> directories, then you can just remove the directories).


<P>

The options <CODE>-p</CODE>, <CODE>-pa</CODE>, and <CODE>-pw</CODE> are extremely useful for use as an aid in reading scripts or debugging
them. If you want to know what script installs <CODE>export/include/foo.h</CODE>, for example, just type:


<P>

<PRE>  cons -pw export/include/foo.h
</PRE>

<P>

<H1><A NAME="B_Using_and_writing_dependency_s"><STRONG>Using and writing dependency scanners</STRONG>

</A></H1>
T.B.S.


<P>

<DT><STRONG><A NAME="item_Last">Last Modified: Thu Jul  2 17:24:03 EDT 1998

</A></STRONG><DD>
</DL>
</DL>
    </BODY>

    </HTML>