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

Subject: Re: [boost] [ot] choosing a build system
From: Allan Johns (nerdvegas_at_[hidden])
Date: 2012-05-08 20:47:28

I've written three build systems in my career (and hopefully no more in
future).

The first was in Jam, which was a horrible experience. Ended up having to
extend Jam itself and add a whole bunch of custom extensions to the Jam
code, in the end it was just too much maintenance. I don't know much about
Boost.Jam but I undestand that it doesn't bear much resemblance to vanilla
Jam, so understand that this is not a critique of Boost.Jam.

The second was written in make from the ground up. It was a lot of work,
but it worked well. I gained an appreciation for make that I did not have
before. But unless you're well versed in make, reading the code of the
resulting system just looks like gobbledigook. It's not particularly
accessible (try explaining to someone what $$$$ means and watch their eyes
glaze over). Having said that, the intent was that only a select few
developers would ever *need* to look under the hood of the build system,
but at the end of the day you still need at least one make guru around.

The third was written in cmake, as part of a more general software
management system (think dependency-resolving packaging system + integrated
build system). The build system came into place much quicker than I
anticipated. I was initially unconvinced about cmake but soon realised that
the idea of having an extra, cross-platform layer over the top of make,
that still used make under the hood, was a really good idea. This was by
far the most successful experience I had with build systems - fastest to
write, least amount of maintenance needed. Cmake has its downsides though,
to be sure - the syntax is at times quirky and annoying - but the
documentation is good and it seems to get you up and running quickly.

I can't say too much about Scons. I have used it in the past, notably at a
game development studio. We ended up keeping it for the data-build, but
ditching it early-on for the code-build. We found dependency tracking to be
very slow (the project was huge though, an entire game engine). Also,
because it's python, it's really flexible, but this isn't necessarily a
good thing... you end up with a program to compile a program, if you will.
This worked in our favour for the data-build, because we had to do all
sorts of crazy stuff to build assets into game-ready state, but for code
this flexibility seemed more a hindrence than a help. I haven't looked at
Scons for a while though, so I can only comment on my experiences with it ~
6 or 7 years ago.

So my vote is cmake, based on my experiences. Hth.
A

On Wed, May 9, 2012 at 9:18 AM, Jeffrey Lee Hellrung, Jr. <
jeffrey.hellrung_at_[hidden]> wrote:

> On Tue, May 8, 2012 at 3:54 PM, Nathan Ridge <zeratul976_at_[hidden]>
> wrote:
>
> >
> > Hello,
> >
> > I am developing a new C++ library (unrelated to Boost) and I need
> > to choose a build system for it.
> >
> > I had originally planned to use Boost.Build, because I figured that
> > it would be particularly suitable for a C++ library, and because
> > I've come to associate Boost with high quality and excellence.
> >
> > However, recently I've heard talk of Boost switching its own build
> > system from Boost.Build to CMake (in fact, the currently active
> > thread about modularization suggests that this change is imminent).
> > My understanding is that Boost is the primary user of Boost.Build,
> > and therefore I am concerned about what this switch means for the
> > future of Boost.Build.
> >
> > Do you think choosing Boost.Build as the build system for a project
> > is still a sound choice, or am I better off choosing something else
> > like CMake?
> >
> > More generally, what build system would you recommend for a C++
> > library?
> >
> > My requirements for the build system are the following:
> >   - straightforward support for multiple variants of the build
> >     (32-bit vs. 64-bit, debug vs. release, static vs. shared, etc.),
> >     including coexistence of multiple variants on the same machine
> >   - general ease of use (for the library writer and library users)
> >   - suitability for a C++ project
> >   - cross-platform, FOSS
> >
> > Any thoughts are appreciated.
> >
>
> Actually the mention of CMake in that very same modularization thread
> piqued my interest as well.
>
> The build system I have the most experience with (and that's not saying too
> much) is SCons, and only because (a) it was the build system on the
> software project I primarily used to develop for; and (b) it encouraged me
> to learn Python, so as far as learning new syntaxes (syntices?), I killed
> two birds with one stone. SCons works for me, I like the fact that it uses
> Python syntax, and I know other people in my research group who also use
> SCons for other projects and enjoy it.
>
> There is a comparison of SCons with other build systems (CMake and
> Boost.Build among them) on the scons.org wiki [1]. That said, if it's not
> too off-topic, I'm also curious to hear from those who've used CMake vs
> Boost.Build (vs SCons?).
>
> - Jeff
>
> [1] http://www.scons.org/wiki/SconsVsOtherBuildTools
>
> P.S.: There's this quote from [1]: "The Boost.Build team is seriously
> considering the use of Scons as its low-level build substrate." How long
> ago was this?
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>