Fwd: [ANN] Mason 1.0

---------- Forwarded message ----------
From: Colin Putney <[hidden email]>
Date: 2009/12/13
Subject: [squeak-dev] [ANN] Mason 1.0
To: The general-purpose Squeak developers list
<[hidden email]>


Hi folks,

As I mentioned yesterday, here's the release version of Mason, a
Squeak build system. It relies on OSProcess to build images, but it
should be possible to build other artifacts, such as directory trees,
zip files, SAR files etc without OSProcess. The download is available
here:

http://www.wiresong.ca/downloads/Mason-1.0.0.sar

There's no documentation yet, but I've pasted below a brief
description that I sent to the Pharo folks a little while ago.

Cheers,

Colin

---

The core model is a hierarchy of targets. Targets represent the
artifacts that Mason can produce, such as files, directories, images,
packages etc, and the hierarchy represents the desired state, which
Mason will work to create. There's a Canvas-like API for creating
target hierarchies, and Products are objects that know how to specify
targets using that API.

A Product is an abstract thing, which represents a high-level concept
such as "the latest version of a given package" or "the HTML
documentation for a project." The role of a Product is to reduce that
abstraction to a set of concrete targets which it specifies using the
canvas API. A Product probably has to examine the environment to
decide what targets to specify - it might scan a repository to
determine the latest version of a package or scan a directory of
creole files to determine which HTML files need to be generated.

Given a target hierarchy, Mason can generate a Build. A Build contains
a number of jobs, which collectively create the artifacts specified by
the targets. Jobs essentially MethodObjects, and each do small amounts
of work. The Build is responsible for running the jobs and managing
dependencies between them. The build runs the jobs in parallel where
possible, and since many jobs involve IO or spawning other processes
via OSProcess, so there's actually a pretty decent performance
advantage.

Those are the broad outlines. There's a few issues here still, both
architectural and with the current implementation.

One is that building a target tree may be an unnecessary intermediate
step. It would feasible to have targets just be transient entities the
way TagBrushes are in Seaside - Products would specify a Build
directly. Another is that I haven't tried to do any optimization along
the lines of make - everything is built fresh every time. The targets
-> build converter could try to examine the disk and see if it could
avoid building things that are already up to date.

I have an idea to address both these issues by having a step that
walks over the target tree and optimizes it before the Build is
created. This could involve identifying and merging common
intermediate steps, and then doing the make trick of eliminating any
targets that already exist and are up-to-date.

For now though, I've been quite happy with even the unoptimized
version. I've used it to build distribution SAR archives for OB, MC2
and Filesystem, development images, load-order and package dependency
testing etc.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project