ANN: Capon 0.1 - a software build framework

[Steven Knight]

Hi--

> > So how does Capon differ from SCons?

I originally replied to this question directly to Aahz with some
information about SCons.  He suggested this was of general interest and
that I share the info with the list.

Since I'm the project lead for SCons, please keep in mind the usual
caveats about my own biases, the fact that I don't know Capon as well as
I know SCons, etc...

> SCons has lots of features.  The main thrust of Capon is on providing
> the means to add features.

SCons has a lot of features partly because we've put a lot of emphasis
on clean APIs for adding features.  For example, SCons does have a lot
of canned, out-of-the-box objects for building programs, object files,
libraries, tar and zip files, pre-compiled headers, MSVC++ resource
files, and various document formats.  However, SCons creates these using
the same API that you'd use yourself if you were defining your own
Builder object.  User feedback indicates that this makes it very easy to
extend SCons.

>                             Capon is a language by itself, and Capon
> scripts are not Python scripts.  That sounds complex but isn't, the
> language is just Python in disguise.

Anders is alluding to the fact that the canonical SCons interface is
that build files are Python scripts that call the build-engine API.

This isn't the only way to use SCons functionality, though.  The SCons
build engine has been designed from the ground up as a separate set of
modules from the Python-script external interface.  You can thus embed
the SCons build engine in any other interface you want.

For example, Stephen Kennedy has already integrated the SCons build
engine with Python FAM (http://sourceforge.net/projects/python-fam) to
create a prototype continuous-integration build GUI, with very fast
rebuild times.  Asko Kauppi is even working at putting a Lua interface
around it...!

> It's not inconceivable that I could find a straightforward way to
> bridge Capon and SCons, providing "Caponic" style access to SCons
> features.  It's not inconceivable that someone else could, either,
> given the extensible nature of Capon.

Actually, this would be pretty easy to do, given the separability of the
SCons build engine that I described above.  (And we'd love to support
more interfaces... :-)

> Take a look at this implementation of 'clean', a function to delete
> intermediary files.
> 
> | import os  # import a Python module
> | .clean():  # lazy notation; think of this as "def clean(self):"
> |     # dependency_tree() is a generator that lists dependencies recursively
> |     for dep in .dependency_tree():
> |         dep.clean_this()
> |
> | .clean_this():
> |     pass
> |
> | .file.gen/clean_this():
> |     if .exists():
> |         if .verbose:
> |             print "clean() deleting %s" % (.filename,)
> |         os.unlink(.filename)
> 
> 'clean' is a simple function that walks a generator and calls
> 'clean_this' on each node.  The nodes typically represent files but
> don't have to.  Except for implicit self argument lists and function 
> bodies are straight Python.

The SCons build engine has a Node-based internal structure that
sounds very similar to this.  It looks to me like in Capon, you add
capabilities by writing Node methods directly, whereas in SCons you go
through an API.  (Anders, please correct me if I'm mistaken.)

The SCons Node infrastructure has pretty robust subclassing for the file
system Nodes, with clean separation between the dependency management
parts (in the base class) and the file-system-specific stuff in the
subclass.  File system Nodes are further subclassed so you can actually
have a build depend on a *directory*.  A directory's "build" consists of
building all of its contents (including subdirectories).  This comes in
really handy for packaging trees into tar and zip files.

If anyone has any follow-on questions about SCons, please let me know.
Thanks!

        --SK