Re: [Boost-build] Future development

From: David Abrahams (dave_at_[hidden])
Date: 2007-10-04 21:27:11

on Thu Oct 04 2007, Ray Lambert <codemonkey-AT-interthingy.net> wrote:

>     IMHO, I don't believe that the problem is related to the
>     declarative parts of the Boost.Build Jamfiles (i.e. "exe",
>     "project" and their "requirements", "usage-requirements"
>     etc). This is what should be retained even with a Python (or
>     other) port as description files.
>
> I thought I'd add my $0.02 to this discussion from the perspective
> of a user of BB.
>
> First, I totally agree with the quoted statement.  Whatever
> direction you go in, please be sure to preserve this along with the
> basic BB model (i.e. the build 'smarts' are in the tool).
>
> Second, no disrespect intended towards the cmake developers, but I
> think the cmake idea is a very bad path.
>
> When I was looking for a build system for my new project earlier
> this year, I rejected cmake and decided to go with BB for very
> specific reasons.

All due respect to your intuition about cmake, but this would carry
much more weight for me coming from someone who had actually used it.

> After looking into gnu automake and it's complexity, it dawned on me
> (actually, I had just never considered it before) that anything
> based on the traditional make system is a waste of time because make
> itself is antiquated and decrepit and no longer solves the problem
> it was originally intended to solve very well.  Software development
> has moved forward but make has not; it's still stuck in the 1970's
> and Bell labs.  It's high time for a new solution.

In the same way that assembly-language programming is antiquated and
almost nobody does it anymore... except compilers.  CMake is just a
compiler that produces makefile "assembly-language."

> Ant goes a long way in this direction but it's too java-specific.
> Add to that the fact that I think XML is a very poor user<->computer
> interface; who really likes hand-coding XML?  Not I.
>
> Any solution that builds on top of make is a waste of time because
> all it's doing is extending the life of something that's really
> already dead for all intents and purposes (it just doesn't know it
> yet).  

By what measure is it already dead?

> I want a real cure; not band aids.  (In the interest of full
> disclosure, I had a bad experience a few years back trying to build
> an imake-based build system; what a hack imake is!)

You don't need a cure for make if you don't try to express your
high-level build ideas in its weak language.  Tell them to
Boost.Build/CMake and let it generate nicely-functioning assembly
language that does what you need.

> In my search (which, admittedly, was probably not as exhaustive as
> it could have been), the only tools (aside from ant) that I found
> that truly had something new to bring to the table were SCons and
> BB.
>
> I liked BB's syntax immediately but I had trouble getting it to work
> (better documentation would have helped so I am glad to see
> documentation is a priority going forward).  So I gave SCons a try
> for a while.  At first it seemed pretty good but I quickly ran into
> trouble.
>
> I believe in the idea that was put forward by Alan Kay: "Simple
> things should be simple and complex things should be possible."
>
> Alas, SCons failed this test (for me, at least).  Very simple things
> were indeed simple to implement.  However, even something moderately
> hard quickly rose to the level of being difficult to the point of
> being almost impossible (and certainly beyond the limits of my
> patience, which, for me, amounts to about the same thing).

I find Boost.Build to be the same way... and I was initimately
involved in its design and development.

> So I tried BB again.  This time I got it to work and I've never
> looked back since.

Have you ever had to do something moderately hard in BB?

> I see BB as being new and innovative in many ways.  The syntax is a
> dream (except for a few jam-related farts, such as spaces before
> semis, etc.)  Requirements are great.  Most importantly, the concept
> that the tool knows what needs to be done is revolutionary, in my
> eyes.  How many times do programmers have to re-teach these things
> to make and it's ilk?  e.g.  How many nasty hacked extended
> dependency solutions must one create to keep make chugging along?
> BB knows all this stuff and automatically does the right thing (in
> most cases, certainly all basic cases).
>
> So, IMO, this is the real value of BB and this core needs to be
> preserved.  

Agreed.  I think Doug's work tries to do that.

> cmake, IMO, would be a step backwards from this (I'm
> trying to get away from other build systems and obsolete ones;
> adding an extra layer to allow an obsolete system work correctly
> just makes the whole thing more complex; a pig in a pretty dress is
> still a pig.)

Even as a replacement for bjam?

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com