Re: [boost] [ot] choosing a build system

Subject: Re: [boost] [ot] choosing a build system
From: Dave Abrahams (dave_at_[hidden])
Date: 2012-05-12 00:03:25

on Fri May 11 2012, Beren Minor <beren.minor+boost-AT-gmail.com> wrote:

>> That's obviously wrong; we are building all of Boost (including its
>> executables) cross-platform with single build files and little or no
>> platform switching.
>
> Well, I wasn't saying that you can't do that with CMake. CMake being a
> language, you can probably do whatever you want with it as long as you
> write the code for doing it.
>
> I was saying that you can't do that with the simple building rules
> CMake provides out-of-the-box. I mean, without going beyond where a
> developer would want to go to define the build targets of his project.
> For me, currently this limit is: if you have to write more than what
> Boost.Build would require you to write, then you are already too far
> into the build system internals.
>
> As an example, creating a library should be as simple as:
> lib foo : bar.c ;
> Or whichever syntax fits you best.
>
> Going back to what you said, I quickly went to the Ryppl sources, and
> that is exactly what I meant. You had to write an entire framework in
> CMake language, 

It's tiny!  And about half of those files (the FindXXX.cmake files)
should be pushed upstream to the CMake maintainers, because they're
useful to all CMake users.  Daniel Pfeifer has done a great job of
walking the line between providing abstraction and leaving things in a
form that regular CMake users (of which there are many) will understand.

> wrapping the CMake built-in rules, to provide a such usable and
> high-level syntax to the developers so their project's CMakeLists
> files will be as easy to write as they were with
> Boost.Build. Basically, you've rewritten a Boost.Build like framework
> in CMake, as Boost.Build is written over Jam. I never said this to be
> impossible.

Try counting lines of code and you'll see that there's no comparison.

> Then, the initial question was about choosing between CMake and
> Boost.Build. And I said that the two are at a totally different level
> of abstraction. It is like, the other way around, comparing the
> framework you have built using CMake vs Jam.

Jam does not begin to approach what CMake provides out-of-the-box.  And
I don't have to maintain any of the latter stuff.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com