Cons - A Software Construction System

A guide and reference for version 2.2.0

Copyright (c) 1996-2000 Free Software Foundation, Inc.

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; see the file COPYING. If not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.

Cons 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.

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. Construction environments 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 signatures are associated with derived files, and are used to accurately determine whether a given file needs to be rebuilt.

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.

Cons is a make replacement. In the following paragraphs, we look at a few of the undesirable characteristics of makeand typical build environments based on makethat motivated the development of Cons.

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 overextended 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.

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.

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.

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.

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.

Cons is Perl-based. That is, Cons scripts--Conscript and Construct files, the equivalent to Makefile or makefileare 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.

To ground the following discussion, here's how you could build the Hello, World! C application with Cons:

  $env = new cons();
  Program $env 'hello', 'hello.c';

  % cons hello
  cc -c hello.c -o hello.o
  cc -o hello hello.o

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

  $env = new cons(
        CC      =>      'gcc',
        LIBS    =>      'libworld.a'
  );

  Program $env 'hello', 'hello.c';

  Library $env 'libworld', 'world.c';

  % 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

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

  % vi world.c
    [EDIT]
  % 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

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

  % emacs world.h
    [EDIT]
  % cons hello
  gcc -c hello.c -o hello.o
  gcc -o hello hello.o libworld.a

Isn't this expensive? The answer isit 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.

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 sequencing 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 correctlyincluding multi-pass hierarchical buildsis eliminated. We'll discuss this further in the next sections.

A larger build, in Cons, is organized by creating a hierarchy of build scripts. At the top of the tree is a script called Construct. The rest of the scripts, by convention, are each called Conscript. These scripts are connected together, very simply, by the CWBuild, CWExport, and CWImport commands.

The CWBuild command takes a list of Conscript file names, and arranges for them to be included in the build. For example:

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

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

  Build qw(
        parser/Conscript
        drivers/Conscript
        utilities/Conscript
  );

  Build qw(
        display/Conscript
        mouse/Conscript
  );

By default, Cons does not change its working directory to the directory containing a subsidiary Conscript file it is including. This behavior can be enabled for a build by specifying, in the top-level Construct file:

  Conscript_chdir 1;

It is expected that this behavior will become the default in some future version of Cons. To prepare for this transition, builds that expect Cons to remain at the top of the build while it reads in a subsidiary Conscript file should explicitly disable this feature as follows:

  Conscript_chdir 0;

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.

You may pull modules into each Conscript file using the normal Perl CWuse or CWrequire statements:

  use English;
  require My::Module;

The top-level Construct file and all Conscript files begin life in a common, separate Perl package. Cons controls the symbol table for the package so that, the symbol table for each script is empty, except for the Construct file, which gets some of the command line arguments. All of the variables that are set or used, therefore, are set by the script itselfnot by some external script.

Variables can be explicitly imported by a script from its parent script. To import a variable, it must have been exported by the parent and initialized (otherwise an error will occur).

The CWExport command is used as in the following example:

  $env = new cons();
  $INCLUDE = "#export/include";
  $LIB = "#export/lib";
  Export qw( env INCLUDE LIB );
  Build qw( util/Conscript );

  $env = new cons();
  Export qw( env INCLUDE LIB );
  Build qw( util/Conscript );
  $env = new cons(CFLAGS => '-O');
  Build qw( other/Conscript );

Variables exported by the CWExport command can be imported into subsidiary scripts by the CWImport command. The subsidiary script always imports variables directly from the superior script. Consider this example:

  Import qw( env INCLUDE );

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

  Import qw ( env INCLUDE );
  Build qw ( beneath-me/Conscript );

  Import qw ( env INCLUDE );
  Export qw ( env );
  Build qw ( beneath-me/Conscript );

The only constraint on the ordering of build scripts is that superior scripts are evaluated before their inferior scripts. The top-level Construct 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 CWBuild command:

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

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.

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 export, and, in a C environment, provided conventional sub-directories of this directory, such as include, lib, bin, etc.

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

  # Construct file for Hello, World!

  # Where to put all our shared products.
  $EXPORT = '#export';

  Export qw( CONS INCLUDE LIB BIN );

  # Standard directories for sharing products.
  $INCLUDE = "$EXPORT/include";
  $LIB = "$EXPORT/lib";
  $BIN = "$EXPORT/bin";

  # A standard construction environment.
  $CONS = new cons (
        CPPPATH => $INCLUDE,    # Include path for C Compilations
        LIBPATH => $LIB,        # Library path for linking programs
        LIBS => '-lworld',      # List of standard libraries
  );

  Build qw(
        hello/Conscript
        world/Conscript
  );

  # Conscript file for directory world
  Import qw( CONS INCLUDE LIB );

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

  # Internal products
  Library $CONS 'libworld.a', 'world.c';

  # Conscript file for directory hello
  Import qw( CONS BIN );

  # Exported products
  Install $CONS $BIN, 'hello';

  # Internal products
  Program $CONS 'hello', 'hello.c';

  % 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

You'll note that the two Conscript 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 Construct file (in this example), to specify the new locations of the Conscript files. The use of an export tree makes this goal easy.

Note, too, how Cons takes care of little details for you. All the export 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.

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 variant builds, especially if you want the variant builds to co-exist.

Cons provides a simple mechanism that handles all of these requirements. The CWLink command is invoked as in this example:

  Link 'build' => 'src';

  Build qw(
        build/world/Conscript
        build/hello/Conscript
  );

  % 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

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.

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

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 CWcons. Here's one way we could set up the Construct file for our Hello, World! application:

  # Construct file for Hello, World!

  die qq(OS must be specified) unless $OS = $ARG{OS};
  die qq(OS must be "peach" or "banana")
        if $OS ne "peach" && $OS ne "banana";

  # Where to put all our shared products.
  $EXPORT = "#export/$OS";

  Export qw( CONS INCLUDE LIB BIN );

  # Standard directories for sharing products.
  $INCLUDE = "$EXPORT/include";
  $LIB = "$EXPORT/lib";
  $BIN = "$EXPORT/bin";

  # A standard construction environment.
  $CONS = new cons (
        CPPPATH => $INCLUDE,    # Include path for C Compilations
        LIBPATH => $LIB,        # Library path for linking programs
        LIBS => '-lworld',      # List of standard libraries
  );

  # $BUILD is where we will derive everything.
  $BUILD = "#build/$OS";

  # Tell cons where the source files for $BUILD are.
  Link $BUILD => 'src';

  Build (
        "$BUILD/hello/Conscript",
        "$BUILD/world/Conscript",
  );

  % 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

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 CW$INCLUDE for platform-dependent files. Most Conscript files, generating purely platform-independent include files, would not have to change.

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 CWDEBUG=on. 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 essential to do this, since Cons is pretty smart about rebuilding things when you change options.

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

  world.o:834179303 23844c0b102ecdc0b4548d1cd1cbd8c6
  libworld.a:834179304 9bf6587fa06ec49d864811a105222c00

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 .consign entry for that file, in which case that signature is used).

Notice that there is no need for a derived file to depend upon any particular Construct or Conscript fileif 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.

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 .consign entry, if one exists. If these times match, then the signature stored in the .consign 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.

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

The use of these signatures is an extremely simple, efficient, and effective method of improvingdramaticallythe reproducibility of a system.

We'll demonstrate this with a simple example:

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

  % cons hello
  cc -c hello.c -o hello.o
  cc -o hello hello.o
  % cons hello
  cons: "hello" 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: "hello" is up-to-date.
  % cons hello
  cc -c hello.c -o hello.o
  cc -o hello hello.o

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 softwareassuming, of course, that no newer dependency file exists in the local build tree.

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.

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

  Repository qw (
        /usr/experiment/repository
        /usr/product/repository
  );

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

Cons will also search for Construct and Conscript 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 Construct file if the Construct file tells you where the repository is? To get around this, repositories may be specified via CW-R options on the command line:

  % cons -R /usr/experiment/repository -R /usr/product/repository .

If the source code (include the Conscript file) for the library version of the Hello, World! 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:

  % 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

  % pico world.c
    [EDIT]
  % 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

  % rm world.c
  % cons -R /usr/src_only/repository hello
  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

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 .consign files that were created by Cons when generating the derived files.

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):

  % 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

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

  % mkdir $HOME/build1
  % cd $HOME/build1
  % ed hello.c
    [EDIT]
  % cons -R /usr/all/repository hello
  gcc -c hello.c -o hello.o
  gcc -o hello hello.o /usr/all/repository/libworld.a

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

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:

  Repository_Sig_Times_OK 0;

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:

  % mkdir $HOME/build2
  % cd $HOME/build2
  % cons -R /usr/all/repository hello
  cons: "hello" is up-to-date.

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 CWLocal command may be added to a Construct or Conscript file to specify that a certain file or files must appear in the local build directory:

  Local qw(
        hello
  );

  % cons -R /usr/all/repository hello
  Local copy of hello from /usr/all/repository/hello
  cons: "hello" is up-to-date.

Creating local copies is most useful for files that are being installed into an intermediate directory (for sharing with other directories) via the CWInstall command. Accompanying the CWInstall command for a file with a companion CWLocal command is so common that Cons provides a CWInstall_Local command as a convenient way to do both:

  Install_Local $env, '#export', 'hello';

  Install $env '#export', 'hello';
  Local '#export/hello';

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

  % 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

In order to inform the compiler about the repository trees, Cons will add appropriate CW-I flags to the compilation commands. This means that the CWCPPPATH 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 Construct file as follows:

  $env = new cons(
        CC      => 'gcc',
        CPPPATH => '.',
        LIBS    => 'libworld.a',
  );

  % 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

  Repository qw(
        /u1
        /u2
  );

  $env = new cons(
        CPPPATH => 'a:b:c',
  );

  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

  #include "file.h"     /* DON'T USE DOUBLE-QUOTES LIKE THIS */

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

  #include <file.h>     /* USE ANGLE-BRACKETS INSTEAD */

Cons provides a CWRepository_List 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:

  @list = Repository_List;
  print join(' ', @list), "\n";

Cons' handling of repository trees interacts correctly with other Cons featureswhich is to say, it generally does what you would expect.

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 CWLink to a source subdirectory. Cons will search for derived files in the appropriate build subdirectories under the repository tree.

Until now, we've demonstrated invoking Cons with an explicit target to build:

  % cons hello

  % cons                # does not build anything

  % cons .              # builds everything under the top-level directory

  Default '.';

  Default qw(
        hello
        goodbye
  );

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.

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 productthat Cons knows aboutin the specified directory and below. For example:

  % cons build/hello/hello.o

In this example:

  % cons build

If we do, instead:

  % cons export

With Cons, make-style ``special'' targets are not required. The simplest analog with Cons is to use special export 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 tests, then:

  % cons tests

  % cons export

  % cons build

If you want to build just a single test, then you could explicitly name the test (in either the tests directory or the build 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).

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

  % cons .

In conjunction with target selection, build pruning 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 CWcons. Cons also provides, as a convenience, a command line convention that allows you to specify which Conscript files actually get ``built''--that is, incorporated into the build tree. For example:

  % cons build +world

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

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).

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 CWOverride commands, and you specify this on the command line, when you run CWcons:

  % cons -o over export

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

The second type of override is accomplished with the CWOverride command, which looks like this:

  Override <regexp>, <var1> => <value1>, <var2> => <value2>, ...;

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

  $CONS = new cons(
        COPT => '',
        CDBG => '-g',
        CFLAGS => '%COPT %CDBG',
  );

  Override '\.o$', COPT => '-O', CDBG => '';

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:

  % 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: "hello" is up-to-date.
  % cons hello
  cc -g -c hello.c -o hello.o
  cc -o hello hello.o

Note that it is still useful to provide, say, the ability to create a fully optimized version of a system for production usefrom the Construct and Conscript 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.

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

  $env = new cons();

  CC            => 'cc',
  CFLAGS        => '',
  CCCOM         => '%CC %CFLAGS %_IFLAGS -c %< -o %>',
  INCDIRPREFIX  => '-I',
  CXX           => '%CC',
  CXXFLAGS      => '%CFLAGS',
  CXXCOM        => '%CXX %CXXFLAGS %_IFLAGS -c %< -o %>',
  LINK          => '%CXX',
  LINKCOM       => '%LINK %LDFLAGS -o %> %< %_LDIRS %LIBS',
  LINKMODULECOM => '%LD -r -o %> %<',
  LIBDIRPREFIX  => '-L',
  AR            => 'ar',
  ARFLAGS       => 'r',
  ARCOM         => "%AR %ARFLAGS %> %<\n%RANLIB %>",
  RANLIB        => 'ranlib',
  AS            => 'as',
  ASFLAGS       => '',
  ASCOM         => '%AS %ASFLAGS %< -o %>',
  LD            => 'ld',
  LDFLAGS       => '',
  PREFLIB       => 'lib',
  SUFLIB        => '.a',
  SUFLIBS       => '.so:.a',
  SUFOBJ        => '.o',
  ENV           => { 'PATH' => '/bin:/usr/bin' },

  CC            => 'cl',
  CFLAGS        => '/nologo',
  CCCOM         => '%CC %CFLAGS %_IFLAGS /c %< /Fo%>',
  CXXCOM        => '%CXX %CXXFLAGS %_IFLAGS /c %< /Fo%>',
  INCDIRPREFIX  => '/I',
  LINK          => 'link',
  LINKCOM       => '%LINK %LDFLAGS /out:%> %< %_LDIRS %LIBS',
  LINKMODULECOM => '%LD /r /o %> %<',
  LIBDIRPREFIX  => '/LIBPATH:',
  AR            => 'lib',
  ARFLAGS       => '/nologo ',
  ARCOM         => "%AR %ARFLAGS /out:%> %<",
  RANLIB        => '',
  LD            => 'link',
  LDFLAGS       => '/nologo ',
  PREFLIB       => '',
  SUFEXE        => '.exe',
  SUFLIB        => '.lib',
  SUFLIBS       => '.dll:.lib',
  SUFOBJ        => '.obj',

  Objects $env 'foo.c', 'bar.c';

The construction variables are also used for other purposes. For example, CWCPPPATH 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 CW_IFLAGS is created: this corresponds to the CW-I switches required by the C compiler to represent the directories specified by CWCPPPATH.

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 CW_IFLAGS are created on demand, but once set, they remain fixed for the life of the environment.

The CWCFLAGS, CWLDFLAGS, and CWARFLAGS variables all supply a place for passing options to the compiler, loader, and archiver, respectively. Less obviously, the CWINCDIRPREFIX variable specifies the option string to be appended to the beginning of each include directory so that the compiler knows where to find .h files. Similarly, the CWLIBDIRPREFIX variable specifies the option string to be appended to the beginning of each directory that the linker should search for libraries.

Another variable, CWENV, is used to determine the system environment during the execution of an external command. By default, the only environment variable that is set is CWPATH, 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 Construct file (or perhaps by importing an appropriate construction package with the Perl CWuse command). The default variables are intended to get you off the ground.

Construction environment variables may be interpolated in the source and target file names by prefixing the construction variable name with CW%.

  $env = new cons(
        DESTDIR =>      'programs',
        SRCDIR  =>      'src',
  );
  Program $env '%DESTDIR/hello', '%SRCDIR/hello.c';

The list of default construction methods includes the following:

The CWnew method is a Perl object constructor. That is, it is not invoked via a reference to an existing construction environment reference, but, rather statically, using the name of the Perl package where the constructor is defined. The method is invoked like this:

  $env = new cons(<overrides>);

The CWclone method creates a clone of an existing construction environment, and can be called as in the following example:

  $env2 = $env1->clone(<overrides>);

The CWcopy 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:

  %env = $env1->copy(<overrides>);

  %cons = new cons()->copy();
  $cons{ENV}{PATH} = "<your path here>";
  $cons = new cons(%cons);

The CWInstall 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:

  Install $env <directory>, <names>;

The CWInstallAs method arranges for the specified source file(s) to be installed as the specified target file(s). Multiple files should be specified as a file list. 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:

CWInstallAs works in two ways:

Single file install:

  InstallAs $env TgtFile, SrcFile;

  InstallAs $env ['tgt1', 'tgt2'], ['src1', 'src2'];

  @srcs = qw(src1 src2 src3);
  @tgts = qw(tgt1 tgt2 tgt3);
  InstallAs $env [@tgts], [@srcs];

The CWPrecious method asks cons not to delete the specified file or list of files before building them again. It is invoked as:

  Precious <files>;

The CWCommand 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). CWCommand is called as follows:

  Command $env <target>, <inputs>, <construction command>;

Within the construction command, any variable from the construction environment may be introduced by prefixing the name of the construction variable with CW%. 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. A doubled CW%% will be replaced by a single CW% in the construction command.

There are several pseudo variables which will also be expanded: The target file name (in a multi-target command, this is always the first target mentioned). Same as CW%>. These refer to the first through ninth input file, respectively. The full set of inputs. If any of these have been used anywhere else in the current command line (via CW%1, CW%2, etc.), then those will be deleted from the list provided by CW%<. Consider the following command found in a Conscript file in the test directory:

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

  echo test/bar test/baz -i test/foo > test/tgt
  echo test/foo test/baz -i test/bar >> test/tgt
  echo test/foo test/bar -i test/baz >> test/tgt

Any of the above pseudo variables may be followed immediately by one of the following suffixes to select a portion of the expanded path name:

  :a    the absolute path to the file name
  :b    the directory plus the file name stripped of any suffix
  :d    the directory
  :f    the file name
  :s    the file name suffix
  :F    the file name stripped of any suffix

It is possible to programmatically rewrite part of the command by enclosing part of it between CW%[ and CW%]. This will call the construction variable named as the first word enclosed in the brackets as a Perl code reference; the results of this call will be used to replace the contents of the brackets in the command line. For example, given an existing input file named tgt.in:

  @keywords = qw(foo bar baz);
  $env = new cons(X_COMMA => sub { join(",", @_) });
  Command $env 'tgt', 'tgt.in', qq(
        echo '# Keywords: %[X_COMMA @keywords %]' > %>
        cat %< >> %>
  );

  echo '# Keywords: foo,bar,baz' > tgt
  cat tgt.in >> tgt

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.

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.

The first word of each command string, after expansion, is assumed to be an executable command looked up on the CWPATH environment variable (which is, in turn, specified by the CWENV 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 CWDepends 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.

If any command (even one within a multi-line command) begins with CW[perl], the remainder of that command line will be evaluated by the running Perl instead of being forked by the shell. If an error occurs in parsing the Perl or if the Perl expression returns 0 or undef, the command will be considered to have failed. For example, here is a simple command which creates a file CWfoo directly from Perl:

  $env = new cons();
  Command $env 'foo',
    qq([perl] open(FOO,'>foo');print FOO "hi\\n"; close(FOO); 1);

  $env = new cons();
  sub create_file {
        my $file = shift;
        open(FILE, ">$file");
        print FILE "hi\n";
        close(FILE);
        return 1;
  }
  Command $env 'foo', "[perl] &create_file('%>')";

Cons normally prints a command before executing it. This behavior is suppressed if the first character of the command is CW@. Note that you may need to separate the CW@ from the command name or escape it to prevent CW@cmd from looking like an array to Perl quote operators that perform interpolation:

  # The first command line is incorrect,
  # because "@cp" looks like an array
  # to the Perl qq// function.
  # Use the second form instead.
  Command $env 'foo', 'foo.in', qq(
        @cp %< tempfile
        @ cp tempfile %>
  );

  cd foo

  cd $<:d; tar cf $>:f $<:f

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:

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

The CWObjects method arranges to create the object files that correspond to the specified source files. It is invoked as shown below:

  @files = Objects $env <source or object files>;

The CWProgram method arranges to link the specified program with the specified object files. It is invoked in the following manner:

  Program $env <program name>, <source or object files>;

Source files may be specified in place of objects filesthe CWObjects method will be invoked to arrange the conversion of all the files into object files, and hence all the observations about the CWObjects 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 CWLINKCOM construction variable, with CW%< set to the object files to be linked (in the order presented), and CW%> set to the target (see the CWCommand method for expansion details). The user may set additional variables in the construction environment, including CWLINK, to define which program to use for linking, CWLIBPATH, a colon-separated list of library search paths, for use with library specifications of the form -llib, and CWLIBS, specifying the list of libraries to link against (in either -llib form or just as pathnames. Relative pathnames in both CWLIBPATH and CWLIBS are interpreted relative to the directory in which the associated construction environment is created (absolute and top-relative names may also be used). Cons automatically sets up dependencies on any libraries mentioned in CWLIBS: those libraries will be built before the command is linked.

The CWLibrary method arranges to create the specified library from the specified object files. It is invoked as follows:

  Library $env <library name>, <source or object files>;

Source files may be specified in place of objects filesthe CWObjects method will be invoked to arrange the conversion of all the files into object files, and hence all the observations about the CWObjects 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 CWARCOM construction variable, with CW%< set to the library members (in the order presented), and CW%> to the library to be created (see the CWCommand method for expansion details). The user may set variables in the construction environment which will affect the operation of the command. These include CWAR, the archive program to use, CWARFLAGS, which can be used to modify the flags given to the program specified by CWAR, and CWRANLIB, the name of a archive index generation program, if needed (if the particular need does not require the latter functionality, then CWARCOM must be redefined to not reference CWRANLIB).

The CWLibrary 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!).

The CWModule method is a combination of the CWProgram and CWCommand 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:

  Module $env <module name>, <source or object files>, <construction command>;

The CWDepends method allows you to specify additional dependencies for a target. It is invoked as follows:

  Depends $env <target>, <dependencies>;

A set of identical dependencies for multiple targets may be specified using 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:

  Depends $env ['foo', 'bar'], 'input_file_1', 'input_file_2';

The CWIgnore method allows you to ignore explicitly dependencies that Cons infers on its own. It is invoked as follows:

  Ignore <patterns>;

If, for example, a program is built in an NFS-mounted directory on multiple systems that have different copies of stdio.h, the differences will affect the signatures of all derived targets built from source files that CW#include <stdio.h>. This will cause all those targets to be rebuilt when changing systems. If this is not desirable behavior, then the following line will remove the dependencies on the stdio.h file:

  Ignore '^/usr/include/stdio\.h$';

The CWSalt method adds a constant value to the signature calculation for every derived file. It is invoked as follows:

  Salt $string;

  Salt `uname -s`;

The CWUseCache method instructs Cons to maintain a cache of derived files, to be shared among separate build trees of the same project.

  UseCache("cache/<buildname>") || warn("cache directory not found");

The CWSourcePath mathod returns the real source path name of a file, as opposted to the path name within a build directory. It is invoked as follows:

  $path = SourcePath <buildpath>;

The CWConsPath method returns true if the supplied path is a derivable file, and returns undef (false) otherwise. It is invoked as follows:

  $result = ConsPath <path>;

The CWSplitPath method looks up multiple path names in a string separated by the default path separator for the operating system (':' on UNIX systems, ';' on Windows NT), and returns the fully-qualified names. It is invoked as follows:

  @paths = SplitPath <pathlist>;

The CWDirPath method returns the build path name(s) of a directory or list of directories. It is invoked as follows:

  $cwd = DirPath <paths>;

  $cwd = DirPath '.';

The CWFilePath method returns the build path name(s) of a file or list of files. It is invoked as follows:

  $file = FilePath <path>;

The CWHelp method specifies help text that will be displayed when the user invokes CWcons -h. This can be used to provide documentation of specific targets, values, build options, etc. for the build tree. It is invoked as follows:

  Help <helptext>;

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 CWnew constructor, and the CWclone and CWcopy methods to create hybrid environments. These changes can be entirely transparent to the underlying Conscript files.

For slightly more demanding changes, you may wish to add new methods to the CWcons package. Here's an example of a very simple extension, CWInstallScript, 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:

  # 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) = @_;
        Command $env $dst, $src, qq(
                sed s+your-path-here+$BIN_DIR+ %< > %>
                chmod oug+x %>
        );
  }

  InstallScript $env "$BIN/foo", "foo.tcl";

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

The following example defines a new package CWcons::switch which overrides the standard CWLibrary 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.

  package cons::switch;
  BEGIN {@ISA = 'cons'}

  sub new {
        shift;
        bless new cons(@_);
  }

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

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

The CWcons command is usually invoked from the root of the build tree. A Construct file must exist in that directory. If the CW-f argument is used, then an alternate Construct file may be used (and, possibly, an alternate root, since CWcons will cd to Construct file's containing directory).

If CWcons is invoked from a child of the root of the build tree with the CW-t argument, it will walk up the directory hierarchy looking for a Construct file. (An alternate name may still be specified with CW-f.) The targets supplied on the command line will be modified to be relative to the discovered Construct file. For example, from a directory containing a top-level Construct file, the following invocation:

  % cd libfoo/subdir
  % cons -t target

  % cons libfoo/subdir/target

The command is invoked as follows:

  cons <arguments> -- <construct-args>

And construct-args can be any arguments that you wish to process in the Construct file. Note that there should be a -- separating the arguments to cons and the arguments that you wish to process in the Construct file.

Processing of construct-args can be done by any standard package like Getopt or its variants, or any user defined package. cons will pass in the construct-args as @ARGV and will not attempt to interpret anything after the --.

  % cons -R /usr/local/repository -d os=solaris +driver -- -c test -f DEBUG

  -R /usr/local/repository -d os=solaris +driver

  -c test -f DEBUG

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

  % cons -pw export/include/foo.h

QuickScan allows simple target-independent scanners to be set up for source files. Only one QuickScan scanner may be associated with any given source file and environment.

QuickScan is invoked as follows:

  QuickScan CONSENV CODEREF, FILENAME [, PATH]

The subroutine is called once for each line in the file, with CW$_ set to the current line. If the subroutine needs to look at additional lines, or, for that matter, the entire file, then it may read them itself, from the filehandle SCAN. It may also terminate the loop, if it knows that no further include information is available, by closing the filehandle.

Whether or not a lookup path is provided, QuickScan first tries to lookup the file relative to the current directory (for the top-level file supplied directly to QuickScan), or from the directory containing the file which referenced the file. This is not very general, but seems good enoughespecially if you have the luxury of writing your own utilities and can control the use of the search path in a standard way. Finally, the search path is, currently, colon separated. This may not make the NT camp happy.

Here's a real example, taken from a Construct file here:

  sub cons::SMFgen {
      my($env, @tables) = @_;
      foreach $t (@tables) {
          $env->QuickScan(sub { /\b\S*?\.smf\b/g }, "$t.smf",
                          $env->{SMF_INCLUDE_PATH});
          $env->Command(
              ["$t.smdb.cc","$t.smdb.h","$t.snmp.cc","$t.ami.cc", "$t.http.cc"],
              "$t.smf",
              q(
                smfgen %( %SMF_INCLUDE_OPT %) %<
              )
          );
      }
  }

This finds all names of the form <name>.smf in the file. It will return the names even if they're found within comments, but that's OK (the mechanism is forgiving of extra files; they're just ignored on the assumption that the missing file will be noticed when the program, in this example, smfgen, is actually invoked).

A scanner is only invoked for a given source file if it is needed by some target in the tree. It is only ever invoked once for a given source file.

Here is another way to build the same scanner. This one uses an explicit code reference, and also (unecessarily, in this case) reads the whole file itself:

  sub myscan {
      my(@includes);
      do {
          push(@includes, /\b\S*?\.smf\b/g);
      } while <SCAN>;
      @includes
  }

    QuickScan $env \myscan, "$_.smf";

Cons is maintained by the user community. To subscribe, send mail to cons-discuss-request@gnu.org with body subscribe.

Please report any suggestions through the cons-discuss@gnu.org mailing list.

Sure to be some. Please report any bugs through the bug-cons@gnu.org mailing list.

Information about CONS can be obtained from the official cons web site http://www.dsmit.com/cons/ or its mirrors listed there.

The cons maintainers can be contacted by email at cons-maintainers@gnu.org

Originally by Bob Sidebotham. Then significantly enriched by the members of the Cons community cons-discuss@gnu.org.

The Cons community would like to thank Ulrich Pfeifer for the original pod documentation derived from the cons.html file. Cons documentation is now a part of the program itself.