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@gmail.com> wrote:
On Tue, May 8, 2012 at 3:54 PM, Nathan Ridge <zeratul976@hotmail.com> 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