From: Ames, Andreas \(Andreas\) (ames_at_[hidden])
Date: 2007-05-10 10:36:14
sorry for jumping in. Although I've used several build systems
(in the sense of writing build scripts, e.g. make, ant, scons etc.)
I have no experience with build script generators like CMake or MPC.
Nevertheless I have reservations against them, see below. These
may be prejudices and I'd be happy to be disabused.
> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]] On Behalf Of David Abrahams
> Sent: Thursday, May 10, 2007 3:35 PM
> Subject: Re: [boost] Boost building with CMake
> on Wed May 09 2007, "Gennadiy Rozental"
> <gennadiy.rozental-AT-thomson.com> wrote:
> > 3. Do we (boost developers) really have any problems with BBv2?
> Yes, I do. I started that project, so I have a vested interest in it.
> Still, I'm just about ready to stop sinking any more time into it.
> Just off the top of my head:
> - the build process part of bjam is inscrutable even to experts
> - the language in which it is written is used in no other tool or
> project, thus presenting a barrier-to-entry for volunteers.
I'd expect that at least these two objections also apply to CMake.
Both of them may be tolerable. What I have doubts about is the
By using generated build scripts you leave the users (both library
developers and end-users) with whatever more or less broken build tools
their platforms happen to provide. As examples, I think some problems
of make are well-known (see http://miller.emu.id.au/pmiller/books/rmch/)
and I know from experience how horrible Visual Studios scales and misses
I'm also uncertain how users can be supported when they encounter
problems with their build tool. Instead of a single build tool with a
lot of compilers, you'd need expertise for a lot of build tools with
another lot of compilers. You just multiply the problems (that might
not be true for KDE, as I'd expect them to support fewer build tools,
platforms and/or compilers than boost).
The core business of build tools is dependency tracking and thus it might
be unfair to compare CMake with build tools (rather than with autotools,
MPC etc). To me the question is, if the build process shouldn't be
optimised for a single, well-known build tool (not necessarily BBv2/bjam;
I have problems myself, integrating it into our make-based build process,
mainly because of the objections mentioned above).
The two objections quoted above can be mitigated with tools like scons and
rake (http://rake.rubyforge.org/). I know, scons has already been ruled
out for whatever reasons, but perhaps rake is already there (I haven't
used it yet)?
-- Andreas Ames | Programmer | Comergo GmbH | ames AT avaya DOT com Sitz der Gesellschaft: Stuttgart Registergericht: Amtsgericht Stuttgart - HRB 22107 Geschäftsführer: Andreas von Meyer zu Knonow, Udo Bühler, Thomas Kreikemeier
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk