Re: [Boost-users] Eclipse integration of bjam

From: David Abrahams (dave_at_[hidden])
Date: 2008-03-11 20:23:45

on Mon Feb 18 2008, Hendrik Belitz <hbelitz-AT-darkon.info> wrote:

> Rene Rivera wrote:
>> Cmake is *technically* not a build system. It is a meta-build system.
>
> Okay, thanks for clarifying that. Although I think that Rüdigers is looking for
> something you call meta-build system in fact.
>
>
>
>
> Rüdiger,
>
> There is nothing wrong with Boost.Build. It works as it should, and it is a
> very sophisticated alternative to gmake and nmake, offering a much clearer
> syntax and platform independence. But it is still a low-level build
> tool 

I'm keenly aware of several Boost.Build shortcomings, but that's just
not accurate.

> like
> it's competitors. 

Hard to say without knowing what you consider to be its competitors.

> Expect to do a lot of of things by hand which can be solved easily in
> a automated way by using something Rene called a "meta-build" system.

The distinction between "build" and "meta-build" is not low- vs. high-
level.  The only difference is that a meta-build system uses an
intermediate build language and a (non-meta) build system does not.  You
can create a "non-meta" build system that is arbitrarily high-level,
automating as much as you might like.  In fact, Boost.Build is a
high-level build system built atop a low-level substrate called "bjam."

> This is especially an issue for open-source projects which often rely
> on other toolkits and libraries already installed on the system. There
> are definitely some pretty neat ways to define automated detection
> rules for these external dependencies in Boost.Build (in fact, you can
> do these things which any build system), but this might involve a
> tedious amount of work; this is something you can just circumvent by
> using a higher-level tool like automake or (for people who dislike
> automake's approach) CMake.

It sounds like you're confused.  Either the high-level tool does the
work for you or it does not.  In many cases Boost.Build is able to do
this sort of detection, just as CMake or automake would, and I'm willing
to be that it has some detection capabilities that neither of the others
has.  The advantage of a meta-build approach used in CMake and automake
is that they can spend arbitrary amounts of time on detection (once)
without slowing things down every time through the compile/edit/debug
cycle.

> Another good point is the generation of platform-dependent makefiles
> or project files which integrate seamlessly in your current
> development environment. 

Not true for CMake.  You can't decouple the generated makefiles from
CMake and expect to continue development for very long, because CMake
writes *extremely* low-level makefiles that don't even handle such
things as header dependency management.

> Using Eclipse, who might want to have eclipse
> project files for you source tree. For Visual Studio or KDevelop, you
> also want to have building and dependency information. 

OK, for IDE project files, that's true... provided that the IDE can
represent the same kind of high-level information that is represented in
your high-level build system.

> Using low-level build tools, you have to generate these things by
> hand. Using high-level tools, the output will match your desired
> development environment.

That is not a low-level vs. high-level difference, but simply an
important feature difference.  Boost.Build doesn't have the ability to
generate IDE project files yet, so that is an advantage of CMake (but
not of automake).

> To summarize this, low-level tools enable you to use a "define once,
> build everywhere" approach, while high-level tools support the more
> generalized of approach of "define once, develop everywhere". While
> this doesn't matter for smaller projects, the latter approach is
> preferable for all projects involving several developers, maybe even
> on different developing platforms.

All true, but not a distinction that applies to Boost.Build, which was
designed with "define once, develop everywhere" in mind, and achieves
that goal admirably.

-- 
Dave Abrahams
Boost Consulting
http://boost-consulting.com