From: King, Steven R (steven.r.king_at_[hidden])
Date: 2007-10-04 13:31:17
I'm a BB user and just a lurker on this list, but I strongly support
[mailto:boost-build-bounces_at_[hidden]] On Behalf Of Ray Lambert
Sent: Thursday, October 04, 2007 9:02 AM
Subject: Re: [Boost-build] Future development
Johan Nilsson wrote:
IMHO, I don't believe that the problem is related to the
of the Boost.Build Jamfiles (i.e. "exe", "project" and their
"usage-requirements" etc). This is what should be retained even
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
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
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!
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk