Re: [boost] Boost building with CMake

From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2007-05-14 00:57:45

On 5/13/07, Douglas Gregor <doug.gregor_at_[hidden]> wrote:
> On May 13, 2007, at 12:00 PM, Dean Michael Berris wrote:
> > 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.
>
> CMake is a cross-platform makefile/project generator. Much of what
> you like about bjam and BBv2---the ability to specify platform-
> independent build rules, etc.---is also available in CMake.
>

>From the discussion and docs, it does appear that way. It might even
seem more "powerful" and "capable" than BBv2. I guess what I really
like about Boost.Build is the simplicity of the Jamfile, how
succinctly it can (at the trivial and usual case) express the
intentions of the Jamfile author. The deviation from Make in terms of
syntax and semantics is also a welcome change, because much of what's
wrong with Make has been addressed by what's right in BBv2.

Although admittedly, I haven't tried CMake yet -- but I don't see the
need for it yet, now that BBv2 has already met my personal needs in my
projects.

> > 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.
>
> Can we really maintain two separate build systems? And keep them
> synchronized? That has the potential to be far worse than the status
> quo.
>

If the question is "who will maintain the CMake build configuration
for Boost", I think the answer would be whoever has enough CMake
experience. As for maintaining the BBv2 build files, I think the
current people maintaining it (the library authors) could do whatever
they are already doing.

Requiring library authors to maintain two build system configurations
would be too much to ask I think, but if the transition to CMake would
be entertained -- even tried -- then the effort would have to be from
those who can make it happen with the least resistance and disruption
as possible. That way, we can evaluate both systems -- BBv2 and CMake
-- as we go along. I believe we don't have to rush this now because
especially like now IMO BBv2 is holding its own as far as the
distribution build is concerned. Please correct me if I'm wrong in
this assessment.

> > 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.
>
> At this point, I don't think it makes sense for anyone to have made
> up their mind, given than so few people are familiar with CMake.
>

You're probably right. FWIW, I'll try and take a look at CMake as well
-- and try to gain as much working information/knowledge about it.

But I'd guess you know how influential a phenomenon inertia is and
with the amount of investment people have already made into learning
and loving BBv2, I guess one could understand the upfront apprehension
to change.

-- 
Dean Michael C. Berris
http://cplusplus-soup.blogspot.com/
mikhailberis AT gmail DOT com
[phone]