Re: Cons 2.3.0 Released

[Steven Knight]

> There have been numerous features added to cons since 2.2.0 I have
> listed below the significant visible changes to cons (basically the
> crus of the RELEASE notes).

Let me follow up a bit on the big feature in this release, signature
configurability.  It's changed quite a bit since the mailing list
discussion a few months ago.  There are now three distinct keywords that
can be used in a SourceSignature statement or a SIGNATURE construction
variable:

        content         content signature
        stored-content  content signature, as stored in
                        the .consign file if possible
        build           build signature, only useful in a
                        SIGNATURE construction variable
                        (i.e., for derived files)

The defaults are "content" for source files and "build" for derived
files.  I experimented with "stored-content" as the default for source
files.  It's a useful performance optimization, but it can cause
incorrect builds in automated cases where Cons is re-run within one
second (or two on a FAT file system) after a file is updated.  Test
suite issues aside (modifying tests to deal with this wouldn't have been
too problematic), it seemed safest to have the default be guaranteeing
a correct build.  Spurious build errors in an automated build as a
Cons default would be maddening to track down...  And specifying
"stored-content" in a Construct file is easy to do.

The .consign format changed to support configurability, but how this
works in build trees with old .consign files isn't well-defined.  The
regression tests start from a clean slate each time, and it didn't seem
worthwhile to spend more development time working out the details on
what should be, hopefully, a one-time transition.  If you want to be
completely safe starting work with 2.3.0, I recommend blowing away the
.consign files and starting with a fresh build.

Interacting with old .consign files in a Repository populated with
derived files will probably not work as intended, and result in
"unnecessary" recompilations of things already in the Repository.
There's no chance it will actually destroy anything in the Repository,
though, so experimentation should be safe.

If it turns out that, practically, interoperability with old .consign
file formats is really crucial, we can revisit this issue.

Many thanks to everyone who provided feedback on this issue.  The
mailing list discussion pointed out (directly and indirectly) a number
of things that were unnecessary in the original draft design for
signature configurability.  The biggest reason it took so long to
finalize 2.3.0 after that discussion was the time it took to pare down
signature configurability to the simplest interface possible that
supported the necessary functionality.

Off-topic from signatures:  I'd be keenly interested in hearing from
anyone who experiments with building targets using Perl code refs.  This
has the potential to be a very useful and powerful feature, but the
documentation and comments go into detail on why it's still considered
experimental.

        --SK