Re: [boost] Boost building with CMake

From: David Abrahams (dave_at_[hidden])
Date: 2007-05-16 12:59:33

on Sun May 13 2007, "Dean Michael Berris" <dmberris-AT-friendster.com> wrote:

> For whatever it's worth, I'd like to give my opinions about this issue.
>
> 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.
>
> Now I haven't been using Boost (or developing for Boost (yet) for the
> matter) as long as others on the list have so I haven't experienced
> the pain of building BBv1 and then transitioning to BBv2. But I have
> been able to use BBv2 extensively in at least a couple of projects
> (two of which open source, and two of which not open source) and all I
> can say is that it's been a breeze to use.
>
> What I particularly like about BBv2 is how easy it seems to make a
> Jamfile.v2 from scratch and modify it according to your later
> requirements without the pain you usually deal with in the Make family
> of tools. Although I understand the apprehension of maintaining the
> Jam sources (in C most of it) and even the Boost.Build .jam files, I
> for one have seen the benefits of such a system as being part of
> Boost.
>
> I guess the thought of using something not-Boost maintained is brought
> about by the obvious hardships in maintaining .jam files in
> Boost.Build itself, and extending the tool chain as well as the mere
> maintenance of the code to fight fires and squash bugs that seem to be
> never ending.

Yup.  Even with the new Getting Started Guide, just take a look at the
number of complaints we've had on the user's list about being unable
to build Boost 1.34.  So far these are largely issues having to do
with configuring the tools.

> The apprehension I feel in adopting CMake is with the inertia and the
> investment a lot of people have put into (me included) understanding
> and using effectively not only the Boost library but the excellent
> build system that comes with it "for free". I think I won't be alone
> in saying that people who have been burnt by the sheer nightmare that
> is writing a Makefile and maintaining it (even with the autotools)
> welcome the breeze that is Boost.Build and Boost.Jam . I don't know if
> it might be the name "CMake" but anything (IMO) remotely related to
> Make just turns me and a lot of developers who've dealt with it before
> away.

:) I hear ya.

> Now I guess it might be too much to ask, but what if we allow some
> CMake specific stuff into Boost -- I mean, just include the build
> files in there and not require the Boost library to restructure itself
> and/or the files if it would be possible -- and let the users choose
> whether to use Boost.Jam+Boost.Build or CMake when building Boost for
> their system, we might be doing everyone a service by providing viable
> alternatives.

Not everyone; it would just worsen the problem we're trying to solve.
It would create confusion and demand for everyone to support both
systems.

> If someone wants to pick up the task of using CMake to build Boost
> and contribute that knowledge/effort into the library/project, then
> I don't see why we should abandon Boost.Build and Boost.Jam when
> people still seem to want to use it.
>
> It might be a naive question, but why can't we let these build-system
> specific files reside in the distribution and let users pick which one
> works for them? I'm positive we can make the CMake and Boost.Build
> stuff reside in the same distribution and not have to abandon one in
> favor of another.
>
> 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.

The support we've seen for keeping Boost.Build alive is obviously
significant and merits consideration.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
Don't Miss BoostCon 2007! ==> http://www.boostcon.com