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

Subject: Re: [boost] [ot] choosing a build system
From: Beren Minor (beren.minor+boost_at_[hidden])
Date: 2012-05-11 17:30:48

> 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, 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.

I've had to write a build system using CMake some time ago, and I
faced the exact same problem. I had to rewrite tons of stuff, like you
did for Ryppl, to make it usable for individual projects. And I feel
sorry for seing this happening again and again. Basically every
project using CMake rewrites its own macros over CMake built-ins to
satisfy this, more or less complicated and powerful depending on the
project's initial needs.

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.

That said, I can understand that because of CMake being more widely
used, this framework will probably be much more maintainable than
Boost.Build, and much attractive to people who want to expand it. I
don't know, maybe it can achieve what Boost.Build couldn't, being
widely used by other than Boost. But maybe it will be only perfectly
fitted to Boost needs, and not usable enough for other projects. And
maybe people will continue to only remember CMake and rewrite their
own build macros until a new challenger appears that will have all the
right features built-in.

-- 
Beren Minor