Subject: Re: [Boost-build] bjam 4.0.. in C++
From: Matt Chambers (matthew.chambers_at_[hidden])
Date: 2010-05-27 13:41:11
Spencer E. Olson wrote:
> I'd like to hear feedback with regards to the future of Boost.Build/bjam. A
> colleage recently attended BoostCon and came back with the impression that
> Boost.Build would be replaced by Kitware's CMake for Boost's primary build
> system. Apparently, someone asked "who uses Boost.Build in non-Boost
> programming" and very few people raised their hands. On the other hand,
> after the question "who uses cmake in non-Boost packages" and several people
> raised their hand.
I use BBv2 with a multi-tiered cross-platform project: Bumbershoot
depends on ProteoWizard which depends on Boost. These projects are quite
loosely coupled. All of them are built with BBv2. We even use Rene's
extensions system so we build things like zlib and expat from BBv2. We
don't rely on the user already having something installed. We easily
bootstrap and build our own copy of bjam if it's not already built:
The advantage of bjam in this case is it's extremely fast to bootstrap.
I'd be worried about a bjam port based on heavy use of C++ templates and
meta-programming which takes a long time to compile. CMake would be
almost as bad. It's hard to imagine actually bootstrapping it: is there
anyone who actually does that? Like others, I'd like to bjam be faster
at dependency scanning. Although I don't have the profiling statistics
that Rene asked for, I've never gotten the sense that bjam was very
memory heavy except in the case of complex dependency graphs where it
will sometimes use gigs of memory.
I certainly want to see BBv2 used in favor of CMake because it's mostly
declarative. I dislike the morass of procedure calls in a CMake
makefile. I will echo others' obvious sentiments of dissatisfaction with
bjam error messages and syntax pickiness. Although that's not news. :)
I'm very grateful for Rene and Volodya's continued efforts on BBv2.
However, I'm somewhat more supportive of Volodya's effort to port BB's
higher level logic from Jam to Python than I am of replacing bjam's low
level C parsing code with C++, even if it would mean the parser was
easier to maintain. Also, isn't it easier to call simple C routines from
Python than it is to call C++ when high performance is needed?
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