Re: [Boost-build] Future development

From: Ray Lambert (codemonkey_at_[hidden])
Date: 2007-10-04 12:02:11

Johan Nilsson 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.

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.

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).  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!)

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).

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

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.  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.)

Thanks to all the great work that the BB team has put into this and 
please keep it up!

~ray