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