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