From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2007-05-16 02:01:54
Dean Michael Berris wrote:
> For whatever it's worth, I'd like to give my opinions about this
> I've personally handled some serious projects with serious build
> configurations which border from the trivial to the bizarre. I have
> had the experience of trying to build/port an application between
> Windows and Linux more than once while I also try to write libraries
> that will build on either platform. I've tried to do this before with
> "just auto-make and friends" and Boost.Build (v2 mostly) and I all I
> can say is that the first time I tried BBv2 it's simple enough to
> understand and use.
> I for one wouldn't want to see Boost.Build or Boost.Jam deprecated
> because I've greatly benefited from these technologies greatly. I just
> wish I could help make them tools better, or at least help it be the
> tool that the community would like it to be.
+1 from here. I've been using Boost.Build on and off for the last couple of
years, without becoming (and fortunately without having felt the need to
become) an expert on the build system itself.
Boost.Build, at least in its most basic usage, is most often a breeze to use
and especially to maintain. The 'usage-requirements' feature is brilliant
and I really don't want to imagine maintaining build trees without it. I
also like the declarative and, IMHO, uncluttered syntax in Jamfiles.
There are downsides to BB as with anything else; it is based on a pretty
obscure but reasonably capable language (bjam) which isn't the easiest to
learn. OTOH, much of Boost.Builds power probably comes from the
build-oriented language base it stands on. Having Boost.Build available in
another, more wide-spread scripting language such as Ruby - which also can
be used for writing very declarative stuff - would be heaven. Another weak
point is the documentation, and the fact that there's only one real expert
that knows the system inside-out (apologies if I'm stepping on someone's
Having said that, in one way I wouldn't care that much if CMake would be the
preferred build-system for Boost, as long as it would only be possible to
invoke a single command to build all the libraries for a specific
platform/compiler. Personally, I could live without the capability to build
with multiple compilers using a single command.
What I am afraid of, is that Boost.Build development would loose much of its
momentum if it would not be the system used for building the Boost
libraries. The amount of feedback from Boost users that is used in getting
Boost.Build to be _the_ build system for cross-platform C++ development is
crucial to further refinement. Maintaining multiple build system
configurations for Boost is unfortunately not a realistic option, IMHO.
Even if Boost would switch to CMake, I would still continue to use
Boost.Build in my cross-platform projects as long as someone is actively
While I'm at that point (cross-platform) - does anyone know if CMake is
available for OpenVMS? I'm well aware that Boost.Build isn't compatible
with OpenVMS currently, but I also believe that porting the current
system would not be impossible as most of the Jam stuff is VMS-capable.
> So personally, I'd like to still stick with Boost.Build and Boost.Jam
> -- and hope we can articulate the requirements somehow and file
> tickets for them so people can actually pick up where others left off
> and improve Boost.Build and Boost.Jam for everyone's sake. That
> however doesn't mean I would reject a well-meant effort of putting in
> the CMake build instructions/files into the distribution just as long
> as BBv2 and Boost.Jam stay.
Again, +1 for sticking with Boost.Build and Boost.Jam. Better the devil you
But, to enable most people (including me) to be able to make a qualified
judgement: Why not wait until the svn switch, make a complete "cmake" dev
branch of Boost, and implement CMake-based building there to
demonstrate proof of concept? Once that would be done, we would
stand a really good chance to compare the two alternatives.
Just my 0.02 EUR.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk