Re: [scons-devel] about A-A-P

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-04-18 13:36:29

----- Original Message -----
From: "Bram Moolenaar" <Bram_at_[hidden]>

> Your summary sounds good: A Makefile with something extra. That's
what
> I intended it to be. Mostly because many people know about Makefiles,
> thus the recipe should look familiar to them. And Makefiles have
proven
> themselves in practice (although there are some drawbacks, which is
what
> the extensions need to fix).

Hi Bram,

I'm part of a team working on the Boost.Build system, which is not on
your list, though it's built on a Jam variant (and Jam is on your list).
I'm not going to suggest that you base your work on our build system; I
think you should use Scons instead, for various reasons. Steven and I
have been keeping in fairly close communication about the problems of
software construction, and we intend to collaborate in the future. So
far, it looks as though we have carved out different aspects of the
problem on which to concentrate. Scons seems to be handling the problems
of low-level infrastructure and build mechanics - it handles things
which Boost.Build does not, like using md5 signatures to be absolutely
positive the right stuff gets rebuilt, keeping multiple parallel build
processes busy, etc.

Boost.Build is focusing on the high-level problem of multi-project
cross-platform build description, abstraction and normalization of build
tools, and the like. The intention is to make a great environment for
cross-platform software construction by developers for the
compile-debug-edit cycle, such that a project description written with
one platform/compiler in mind stands a very good chance of working well
on many others. We are not focusing on configuration and installation
issues, though we know that's in the future somewhere.

It seems as though A-A-P is biting off a great deal, trying to solve all
the same problems of Boost.Build in addition to the to-say-the-least
nontrivial problems of configuration and installation. I believe that
Boost.Build has solved some of the high-level architectural problems
very well, and I suggest that you try to capitalize on our work. While
you may not be able to use our code, reusing the concepts could make a
superior product possible.

> I've listed the reasons for using a new syntax in the list of
decisions.
> The main reasons are that trying to be compatible with the Makefile
> syntax (BSD or GNU) makes it difficult and awkward to add extensions,
> and I could not find another format that meets the goals for A-A-P.
No,
> SCons scripts don't look very attractive to me. I don't have a Python
> background, that does matter.

Even to a pythonista like me, Scons scripts are extremely tweaky and
hard-to-read. Improved syntax for build specification is one of the few
things that Jam has over Python. You might consider using some front-end
processing which looks more like Boost.Build.

-Dave