[ot] choosing a build system
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. Thanks, Nate
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?
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
AMDG On 05/08/2012 04:18 PM, Jeffrey Lee Hellrung, Jr. wrote:
[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?
This has never been under consideration in my memory. It was probably confused with the Python port of Boost.Build. In Christ, Steven Watanabe
on Tue May 08 2012, Steven Watanabe <watanabesj-AT-gmail.com> wrote:
AMDG
On 05/08/2012 04:18 PM, Jeffrey Lee Hellrung, Jr. wrote:
[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?
This has never been under consideration in my memory. It was probably confused with the Python port of Boost.Build.
No, it's accurate, just very outdated. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 09/05/12 20:17, Dave Abrahams wrote:
on Tue May 08 2012, Steven Watanabe<watanabesj-AT-gmail.com> wrote:
AMDG
On 05/08/2012 04:18 PM, Jeffrey Lee Hellrung, Jr. wrote:
[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?
This has never been under consideration in my memory. It was probably confused with the Python port of Boost.Build.
No, it's accurate, just very outdated.
I would say that 'seriously', in that quote, is indeed inaccurate. This never was considered more seriously than "if SCons ever becomes performant enough, we might look at it". - Volodya
on Tue May 08 2012, "Jeffrey Lee Hellrung, Jr." <jeffrey.hellrung-AT-gmail.com> wrote:
[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?
A long, long time ago, when I was still designing and maintaining Boost.Build :-) -- Dave Abrahams BoostPro Computing http://www.boostpro.com
AMDG On 05/08/2012 03:54 PM, Nathan Ridge wrote:
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?
Vladimir has stated that he intends to continue support for Boost.Build even if Boost itself switches away. At this point, switching to CMake is not a done deal, anyway.
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
You should be able to do this with any build system. Boost.Build supports this directly. For CMake, depending on the backend, you can use separate build directories for each variant.
- general ease of use (for the library writer and library users) - suitability for a C++ project - cross-platform, FOSS
In Christ, Steven Watanabe
________________________________ From: Nathan Ridge <zeratul976@hotmail.com>
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? [snip]
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 [snip]
I used both CMake and Boost.Build for Boost.Locale project and I use CMake for most of my non-Boost-related C++ projects. While Boost.Build makes it easer to handle multi-variant releases in general I find CMake superior. I can point to several major problems with BB: 1. The most important problem of Boost.Build is lack of suitable documentation. While it is not hard to create a simple library or a set of libraries and tests, when it comes to something different than simple task, like dependencies configuration, libraries, options etc. it becomes very hard to work with, understand and find the documentation about. 2. Boost.Build was created for Boost. And boost has a tendency to be self-contained - i.e. all Boost needs is Boost. It is good for Boost but in real world it is frequent to deal with multiple systems, dependencies custom builds etc. And BB less suited for that. Not that it is not doable, but it is hard. Simple stuff like "find a library" or check for a header or some compiler feature (like try compile and see if it works) becomes very verbose. So basically... My opinion, use CMake it would make you much more productive. Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.com/ CppDB - C++ SQL Connectivity: http://cppcms.com/sql/cppdb/
On Wed, 09 May 2012 00:36:39 -0600, Artyom Beilis <artyomtnk@yahoo.com> wrote:
[...]1. The most important problem of Boost.Build is lack of suitable documentation.
I don't know whether my presentation from BoostCon 2011 is anywhere linked from boost.org. Given that the lack of documentation is indeed a huge problem, maybe this helps a bit: https://raw.github.com/boostcon/2011_presentations/master/mon/Boost.Build.pd... Boris
[...]
On 05/18/2012 10:24 PM, Boris Schaeling wrote:
On Wed, 09 May 2012 00:36:39 -0600, Artyom Beilis <artyomtnk@yahoo.com> wrote:
[...]1. The most important problem of Boost.Build is lack of suitable documentation.
I don't know whether my presentation from BoostCon 2011 is anywhere linked from boost.org. Given that the lack of documentation is indeed a huge problem, maybe this helps a bit: https://raw.github.com/boostcon/2011_presentations/master/mon/Boost.Build.pd...
Thank you Boris! Simply put, this is by far the most friendly introduction to understanding of the language and libraries of Boost.Build that I have ever read. This sort of material should be a separate section in the documentation for those needing to do a little more complex tasks, like customizing for a new platform or writing a generator. This provides a good basis for understanding what is going on, not just doing basic standard stuff and hope it works. If nothing else, this presentation should this be linked from somewhere people can find it. E.g: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost.Build_V... -- Bjørn
Bjørn Roald wrote:
On 05/18/2012 10:24 PM, Boris Schaeling wrote:
On Wed, 09 May 2012 00:36:39 -0600, Artyom Beilis <artyomtnk@yahoo.com> wrote:
[...]1. The most important problem of Boost.Build is lack of suitable documentation.
I don't know whether my presentation from BoostCon 2011 is anywhere linked from boost.org. Given that the lack of documentation is indeed a huge problem, maybe this helps a bit: https://raw.github.com/boostcon/2011_presentations/master/mon/Boost.Build.pd...
Thank you Boris!
Simply put, this is by far the most friendly introduction to understanding of the language and libraries of Boost.Build that I have ever read.
aaaaa... not quite. You should take a look at Boris's book on Boost http://xmlpress.net/publications/boost/ Robert Ramey
This sort of material should be a separate section in the documentation for those needing to do a little more complex tasks, like customizing for a new platform or writing a generator. This provides a good basis for understanding what is going on, not just doing basic standard stuff and hope it works.
If nothing else, this presentation should this be linked from somewhere people can find it. E.g: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost.Build_V...
On 05/19/2012 08:30 PM, Robert Ramey wrote:
Bjørn Roald wrote:
On 05/18/2012 10:24 PM, Boris Schaeling wrote:
On Wed, 09 May 2012 00:36:39 -0600, Artyom Beilis <artyomtnk@yahoo.com> wrote:
[...]1. The most important problem of Boost.Build is lack of suitable documentation. I don't know whether my presentation from BoostCon 2011 is anywhere linked from boost.org. Given that the lack of documentation is indeed a huge problem, maybe this helps a bit: https://raw.github.com/boostcon/2011_presentations/master/mon/Boost.Build.pd... Thank you Boris!
Simply put, this is by far the most friendly introduction to understanding of the language and libraries of Boost.Build that I have ever read. aaaaa... not quite. You should take a look at Boris's book on Boost http://xmlpress.net/publications/boost/ Robert Ramey
That book is a friendly book on boost C++ libraries. I was talking about bjam language and Boost.Build as a library of bjam functions. AFAICT the book has very little to say about boost build, except for what you really need to get going. So I think you may have misread my posting. The book is great though. -- Bjørn
Bjørn Roald wrote:
On 05/19/2012 08:30 PM, Robert Ramey wrote:
Bjørn Roald wrote:
On 05/18/2012 10:24 PM, Boris Schaeling wrote:
On Wed, 09 May 2012 00:36:39 -0600, Artyom Beilis <artyomtnk@yahoo.com> wrote:
[...]1. The most important problem of Boost.Build is lack of suitable documentation. I don't know whether my presentation from BoostCon 2011 is anywhere linked from boost.org. Given that the lack of documentation is indeed a huge problem, maybe this helps a bit: https://raw.github.com/boostcon/2011_presentations/master/mon/Boost.Build.pd... Thank you Boris!
Simply put, this is by far the most friendly introduction to understanding of the language and libraries of Boost.Build that I have ever read. aaaaa... not quite. You should take a look at Boris's book on Boost http://xmlpress.net/publications/boost/ Robert Ramey
That book is a friendly book on boost C++ libraries. I was talking about bjam language and Boost.Build as a library of bjam functions. AFAICT the book has very little to say about boost build, except for what you really need to get going. So I think you may have misread my posting. The book is great though.
I didn't misread it - I was expanding on it by adding useful related information. Robert Ramey
On May 18, 2012, at 1:24 PM, Boris Schaeling wrote:
On Wed, 09 May 2012 00:36:39 -0600, Artyom Beilis <artyomtnk@yahoo.com> wrote:
[...]1. The most important problem of Boost.Build is lack of suitable documentation.
I don't know whether my presentation from BoostCon 2011 is anywhere linked from boost.org. Given that the lack of documentation is indeed a huge problem, maybe this helps a bit: https://raw.github.com/boostcon/2011_presentations/master/mon/Boost.Build.pd...
Boris -- Your session can be found at <http://blip.tv/boostcon/boost-process-process-management-in-c-5368233> -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
On Tue, May 8, 2012 at 6: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.
Maybe you can have a look at premake (http://industriousone.com/premake). Its works in a similar way to CMake, that is, it generates project files/makefiles for target platforms, but the nice thing is that it uses Lua as a language. -- François
on Wed May 09 2012, Francois Duranleau <xiao.bai.xiong-AT-gmail.com> wrote:
On Tue, May 8, 2012 at 6: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.
Maybe you can have a look at premake (http://industriousone.com/premake). Its works in a similar way to CMake, that is, it generates project files/makefiles for target platforms, but the nice thing is that it uses Lua as a language.
Wow, that looks like a really beautiful design. Maybe someday it would make sense for Boost. However, as of now that project still looks way less mature and less-well supported than CMake is, and that makes it somewhat inappropriate for Boost or other "important" projects. I would be cautious if I were you. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
----- Mail original -----
De: "Dave Abrahams" <dave@boostpro.com> À: boost@lists.boost.org Envoyé: Mercredi 9 Mai 2012 18:23:24 Objet: Re: [boost] [ot] choosing a build system
on Wed May 09 2012, Francois Duranleau <xiao.bai.xiong-AT-gmail.com> wrote:
On Tue, May 8, 2012 at 6: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.
Maybe you can have a look at premake (http://industriousone.com/premake). Its works in a similar way to CMake, that is, it generates project files/makefiles for target platforms, but the nice thing is that it uses Lua as a language.
Wow, that looks like a really beautiful design. Maybe someday it would make sense for Boost.
I choose premake against CMake because I found it trivial to add something close to "usage requirements" of Boost.Build. (It seems premake might support that out of the box in next version.) I did not really enjoy trying to add that to CMake. Regards, Ivan
on Wed May 09 2012, Ivan Le Lann <ivan.lelann-AT-free.fr> wrote:
I choose premake against CMake because I found it trivial to add something close to "usage requirements" of Boost.Build. (It seems premake might support that out of the box in next version.)
I think that's planned for CMake too.
I did not really enjoy trying to add that to CMake.
Heh, you didn't have to. You could have used Daniel's Ryppl Cmake framework on which the latest modularized Boost is based :-) https://github.com/ryppl/boost-zero/ * The cmake/ subdirectory contains the CMakeLists.txt files for Boost * The ryppl/ submodule contains Ryppl's CMake facilities in its cmake/Modules direcotry But by all means, stay with premake if it's working for you. It would be interesting to hear from you later about what worked (or didn't). Cheers, -- Dave Abrahams BoostPro Computing http://www.boostpro.com
I recommend waf, particularly if you are drawn to scons as extensible in Python.
james wrote:
I recommend waf, particularly if you are drawn to scons as extensible in Python.
In my opinion, waf is quite interesting. But it really doesn't have much momentum compared to scons. I use scons extensively. I am concerned though, that scons development seems to be stopped. Does that mean it is now perfect? Doubt it.
From a personal point of view, Boost.Build (even if not perfect as it is) does what a build system should do: abstract the user all the detail on how the objects will be built and let him only care about
Hi, My 2 cents regarding build systems as I've recently had to write a build framework using CMake and as I use Boost.Build for personal projects. I think Boost.Build and CMake are at a totally different level of abstraction: CMake is low-level when Boost.Build is high-level. For comparison with other build systems, Make, SCons are at the same level as CMake. Premake is probably closer to Boost.Build (I don't know enough others but there's not a lot being as high-level as BBv2). Of course SCons and CMake still have a major advantage over Make because of their portability. But they offer a very little abstraction over simple Make. Surely, there are some built-in rules to easily create shared/static libraries or executables, but you still have to define a lot of things manually. As an example, I quickly realized that CMake is simply unable to create both shared and static version of a library if you don't explicitly write the two rules to build them. For comparison, with Boost.Build, creating a library is as simple as writing: lib foo : bar.c ; Then, depending in which context the library is used, BBv2 will create shared or static or both versions of the library. You don't have to care about the details, you'll have automatic resolution of what is required to satisfy the build request, based on the build condition you asked for. The abstraction level of Boost.Build is also very visible when you start working on multiple compiler and/or multiple build variants. As long as you don't need fancy compiler flags (and I think most projects shouldn't play with fancy compiler flags) you can trust Boost.Build to abstract all the details of the compiler flags and to offer you the possibility to build everything you want, at once. With CMake and others, as comparison, you are only able to build one variant at a time, and by default everything will be build in conflicting way between build variants (build once in release mode and once in debug mode, and you'll overwrite the previous build output). As said, you can use different build folders for different variants, but that's much less easy to use and not very maintainable unless you maintain a wrapper around the build system that does this for you. I like very much Boost.Build, and I was quite disappointed to hear that there's a plan to move Boost to CMake. Boost is the main user of Boost.Build and I'm a little bit afraid of seeing it disappear, or being less and less unsupported. Even if I perfectly understand the reason of this change: Boost.Build suffers from lack of documentation and lack of popularity, whereas CMake is very well documented and widely used, it leaves me a bitter taste in mouth. the high-level objects and their relations. CMake and others are "old-generation" build systems, which may be used as building blocks to achieve this goal. -- Beren Minor
I like very much Boost.Build, and I was quite disappointed to hear that there's a plan to move Boost to CMake. Boost is the main user of Boost.Build and I'm a little bit afraid of seeing it disappear, or being less and less unsupported. Even if I perfectly understand the reason of this change: Boost.Build suffers from lack of documentation and lack of popularity, whereas CMake is very well documented and widely used, it leaves me a bitter taste in mouth.
cmake has one huge advantage over scons or boost.build: it is not a build system itself, but it populates a build system ... it therefore scales quite well (in the contrast to scons). it also has the nice side effect that it it integrates very well into IDEs ... when using kdevelop or qtcreator, you can simply open the root CMakeLists.txt file and it will populate a project for you. this is the reason, why i ended up using a small cmake build system for my boost-related development instead of using boost.build. tim
Tim Blechmann wrote:
I like very much Boost.Build, and I was quite disappointed to hear that there's a plan to move Boost to CMake. Boost is the main user of Boost.Build and I'm a little bit afraid of seeing it disappear, or being less and less unsupported. Even if I perfectly understand the reason of this change: Boost.Build suffers from lack of documentation and lack of popularity, whereas CMake is very well documented and widely used, it leaves me a bitter taste in mouth.
cmake has one huge advantage over scons or boost.build: it is not a build system itself, but it populates a build system ... it therefore scales quite well (in the contrast to scons).
it also has the nice side effect that it it integrates very well into IDEs ... when using kdevelop or qtcreator, you can simply open the root CMakeLists.txt file and it will populate a project for you. this is the reason, why i ended up using a small cmake build system for my boost-related development instead of using boost.build.
Could you post or send me more information on this? I would like to be able to do the following: a) make a small library which looks like a boost library with include, example, test ... b) The library would not be a member of boost. c) But the library would depend upon boost and users of the library could be expected to have boost installed. d) Users would be able to i) download zip/tar file an expand it anywhere on their system ii) if necessary build the library iii) run the test suite and capture the test results iv) use the library in their own projects. all without installing additional software. I've been looking at all the options I can find including Autotools, bjam, simple make files, shell scripts, and CMake. Without going into details, I'm currently taking a hard look at CMake. I'm going through the documents and experimenting. (For some reason, the explanations ((such as the are)) for all the build systems ((exept simple make)) are very opaque to me. So I would be curious to see what you've been using to make a small boost dependent project. Basically, I'm looking for the lazy man's CMake/Boost template. I have found the rypll examples. These depend up on rypll additions to CMake. Since the librar(ies) have in mind wouldn't be part of the boost distribution I would hope I can find a solution which depends only upon plain vanilla CMake. Robert Ramey
tim
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Thu, May 10, 2012 at 5:52 PM, Beren Minor <beren.minor+boost@gmail.com>wrote:
I think Boost.Build and CMake are at a totally different level of abstraction: CMake is low-level when Boost.Build is high-level. For comparison with other build systems, Make, SCons are at the same level as CMake. Premake is probably closer to Boost.Build (I don't know enough others but there's not a lot being as high-level as BBv2).
My understanding is that both CMake and Premake are meta-build system, they don't build anything, only generate build scripts for your favorite tools (make,MSVS, etc. ) So I don't understand your comparisons... Joel Lamotte
My understanding is that both CMake and Premake are meta-build system, they don't build anything, only generate build scripts for your favorite tools (make,MSVS, etc. )
To be honest, it actually matters if you care about integration of the build system with other tools (ie: if it is able to generate Eclipse/VS project files instead of plain old Makefiles), but in my opinion this does not come first when looking at the advantages of a build system (you should be able to configure the IDE to use any build system instead of the opposite). What matters to me is what you have to write in order to describe the way your project can be built. I don't want to lose days writing CMake rules to support this system or this compiler, putting the right flags and building the right targets, I want to spend a few minutes writing simple build rules, and spec the rest of these days writing my CPP code to make it support all the compilers and OSes the build system can address out of the box. Boost.Build allows the user to describe the targets in a very high-level fashion, without having to dive into details or compiler specifics. Whereas with CMake you have to write low level rules, explicitly building shared or static (or both if you write both rules) version of a library, checking compiler capabilities, checking what is the OS where you are, etc... -- Beren Minor
On Thu, May 10, 2012 at 10:52 AM, Beren Minor <beren.minor+boost@gmail.com> wrote:
I think Boost.Build and CMake are at a totally different level of abstraction: CMake is low-level when Boost.Build is high-level. For comparison with other build systems, Make, SCons are at the same level as CMake. Premake is probably closer to Boost.Build (I don't know enough others but there's not a lot being as high-level as BBv2).
Of course SCons and CMake still have a major advantage over Make because of their portability. But they offer a very little abstraction over simple Make. Surely, there are some built-in rules to easily create shared/static libraries or executables, but you still have to define a lot of things manually. As an example, I quickly realized that CMake is simply unable to create both shared and static version of a library if you don't explicitly write the two rules to build them.
I've got the same problems with CMake. Something as simple as a cross-platform build file for a Hello World app or library isn't possible. Need the static runtime (on VC)? Got to hack command line switches. PCH? Not supported. Automatic target naming for multiple library variants? Not supported. -- Olaf
on Thu May 10 2012, Olaf van der Spek <ml-AT-vdspek.org> wrote:
On Thu, May 10, 2012 at 10:52 AM, Beren Minor <beren.minor+boost@gmail.com> wrote:
I think Boost.Build and CMake are at a totally different level of abstraction: CMake is low-level when Boost.Build is high-level. For comparison with other build systems, Make, SCons are at the same level as CMake. Premake is probably closer to Boost.Build (I don't know enough others but there's not a lot being as high-level as BBv2).
Of course SCons and CMake still have a major advantage over Make because of their portability. But they offer a very little abstraction over simple Make. Surely, there are some built-in rules to easily create shared/static libraries or executables, but you still have to define a lot of things manually. As an example, I quickly realized that CMake is simply unable to create both shared and static version of a library if you don't explicitly write the two rules to build them.
I've got the same problems with CMake. Something as simple as a cross-platform build file for a Hello World app or library isn't possible.
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. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
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
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.
My first look was probably too quick, you are not exactly wrapping the CMake built-in rules, but then you still had to add quite a lot of CMake code around. I couldn't find how you managed to create both shared and static versions of the libraries with a single call to add_library, I will have to investigate. -- Beren Minor
on Fri May 11 2012, Beren Minor <beren.minor+boost-AT-gmail.com> wrote:
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.
My first look was probably too quick, you are not exactly wrapping the CMake built-in rules, but then you still had to add quite a lot of CMake code around. I couldn't find how you managed to create both shared and static versions of the libraries with a single call to add_library, I will have to investigate.
I don't think we are doing that. I think it's just a matter of whether BUILD_SHARED_LIBS is turned on or not. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
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
From: beren.minor+boost@gmail.com
[...]
I think Boost.Build and CMake are at a totally different level of abstraction: CMake is low-level when Boost.Build is high-level.
[...]
Boost.Build suffers from lack of documentation and lack of popularity
So is there something that's high-level *and* well-documented/widely used? Thanks, Nate
on Thu May 10 2012, Beren Minor <beren.minor+boost-AT-gmail.com> wrote:
Hi,
My 2 cents regarding build systems as I've recently had to write a build framework using CMake and as I use Boost.Build for personal projects.
I think Boost.Build and CMake are at a totally different level of abstraction: CMake is low-level when Boost.Build is high-level. For comparison with other build systems, Make, SCons are at the same level as CMake. Premake is probably closer to Boost.Build (I don't know enough others but there's not a lot being as high-level as BBv2).
One of the problems people have with Boost.Build is that its high-level abstractions make it hard to control. There's so much going on between the code you write in your Jamfile and the actual command-lines that come out the other end, that it can be hard to know how to get the effect you want. If you need to do something specific for a given platform or compiler, you can't use a simple if/then statement based on some variable; you have to use a creatively-defined declarative language, and hope that the Boost.Build engine makes the choices you intend. I was a major participant in the design of that language, and in principle I think a declarative approach is ideal, but I now accept that the language we have doesn't match up well with the way that most users of the build system think, and that the high level of abstraction is not a net win. Parts of Boost.Build are an elegant design, no doubt. When Troy and Doug started talking up CMake to me, I kept pushing them to implement more of the abstractions in Boost.Build. But I've come to see that many of them aren't needed. Boost is a pretty good test case for complexity, and the CMake files for building boost portably (https://github.com/ryppl/boost-zero/tree/master/cmake) are not especially more complicated than its Jamfiles. But there's an order of magnitude more code in Boost.Build than there is in Ryppl's CMake support (https://github.com/ryppl/ryppl/tree/develop/cmake/Modules).
Of course SCons and CMake still have a major advantage over Make because of their portability. But they offer a very little abstraction over simple Make. Surely, there are some built-in rules to easily create shared/static libraries or executables, but you still have to define a lot of things manually. As an example, I quickly realized that CMake is simply unable to create both shared and static version of a library if you don't explicitly write the two rules to build them.
You mean, in a single build run? This is exactly the sort of situation where I think the abstraction capabilities you're wishing for are a net loss. It's not that much better to write lib foo : a.cpp b.cpp : : <link>static <link>shared ; (or is it <link>static/shared? I forget. And that's part of the problem) than it is to write set(sources a.cpp b.cpp) add_library(foo STATIC ${sources}) add_library(foo SHARED ${sources}) and the latter one matches up really well with what users understand. Furthermore, anyone who wants to build a library both ways with less boilerplate can write a simple function that does it.
For comparison, with Boost.Build, creating a library is as simple as writing: lib foo : bar.c ;
Then, depending in which context the library is used, BBv2 will create shared or static or both versions of the library. You don't have to care about the details, you'll have automatic resolution of what is required to satisfy the build request, based on the build condition you asked for.
...until it surprises you, as in https://trac.lvk.cs.msu.su/boost.build/wiki/AlternativeSelection Sometimes it's better to be a little more verbose and a little less automatic.
The abstraction level of Boost.Build is also very visible when you start working on multiple compiler and/or multiple build variants. As long as you don't need fancy compiler flags (and I think most projects shouldn't play with fancy compiler flags) you can trust Boost.Build to abstract all the details of the compiler flags and to offer you the possibility to build everything you want, at once.
With CMake and others, as comparison, you are only able to build one variant at a time, and by default everything will be build in conflicting way between build variants (build once in release mode and once in debug mode, and you'll overwrite the previous build output).
Meh; you just use different build directories. This is another one of those advantages of Boost.Build that cost more than they deliver, IMO. It means that every Boost.Build target is actually a meta-target representing one or more real targets, which complexity makes the whole system harder to understand and control... and, especially, harder to extend.
As said, you can use different build folders for different variants, but that's much less easy to use and not very maintainable unless you maintain a wrapper around the build system that does this for you.
The advantage of maintaining a thin wrapper over the build system, if you need this kind of thing regularly, is that it's easy to get in underneath this layer and work with the build system directly: to experiment, extend, whatever. And at that level, you're just dealing with a single target and build variant. In the case of Boost.Build, there's no way to separate anything from the possibility of multiple variants, compilers, etc. In the end, most users of the build system don't need to do multiple builds at once anyway, so they never see the wrapper and never even have to deal with that incremental increase in complexity.
I like very much Boost.Build, and I was quite disappointed to hear that there's a plan to move Boost to CMake. Boost is the main user of Boost.Build and I'm a little bit afraid of seeing it disappear, or being less and less unsupported. Even if I perfectly understand the reason of this change: Boost.Build suffers from lack of documentation and lack of popularity, whereas CMake is very well documented and widely used, it leaves me a bitter taste in mouth.
I don't know that the change will happen, but I hope very much that it will. I'm sorry for the bitter taste and for the hurt feelings of those who have invested so much in Boost.Build. However, my priority has to be on what's best for Boost's mission as a vehicle for C++ libraries.
From a personal point of view, Boost.Build (even if not perfect as it is) does what a build system should do: abstract the user all the detail on how the objects will be built and let him only care about the high-level objects and their relations.
The problem with that approach is that when something breaks, you usually end up working backwards from the actual command-lines you need the system to issue, and if the connection between the build description files and those command-lines is too distant, it can be hard to make the leap.
CMake and others are "old-generation" build systems, which may be used as building blocks to achieve this goal.
I think you're not giving CMake enough credit. It has been evolving quite quickly over the past few years. Its programming language may be old and crusty, but it's expressive enough to get the job done. Most importantly, it hits a "sweet spot" between abstract and direct that makes it practical and accessible. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Fri, 11 May 2012 21:56:47 -0600 Dave Abrahams <dave@boostpro.com> wrote:
I think you're not giving CMake enough credit. It has been evolving quite quickly over the past few years. Its programming language may be old and crusty, but it's expressive enough to get the job done. Most importantly, it hits a "sweet spot" between abstract and direct that makes it practical and accessible.
The language isn't the only problem. Remember Makefile generation? It absolutely isn't justified. Autotools uses this approach only to achieve the cool trick of allowing you to make distribution packages that don't require anything other than standard unix utils to be built. It's just easier to make an unitary build tool than mess around with makefile generation and suffer all limitations of this approach. What's so hard about implementing topological sort, anyway? Make isn't magic. All in all, the fact that build tools with such ancient design are still seriously developed is disheartening. Pretty much shows that people don't care much about buildsystems.
Hi,
All in all, the fact that build tools with such ancient design are still seriously developed is disheartening. Pretty much shows that people don't care much about buildsystems.
Well, why should they, as long as they work to their needs? A Build Tool is not an end in itself, it is a tool for a purpose. Why care more than just that it fullfills its purpose? Christof -- okunah gmbh Software nach Maß Werner-Haas-Str. 8 www.okunah.de 86153 Augsburg cd@okunah.de Registergericht Augsburg Geschäftsführer Augsburg HRB 21896 Christof Donat UStID: DE 248 815 055
On Sat, 12 May 2012 10:44:20 +0200 Christof Donat <cd@okunah.de> wrote:
Well, why should they, as long as they work to their needs? A Build Tool is not an end in itself, it is a tool for a purpose. Why care more than just that it fullfills its purpose?
One person's tool is another person's purpose. Design mistakes will cost a lot of extra work in the grand scheme of things. Both for tool writers and for tool users.
Hi,
Well, why should they, as long as they work to their needs? A Build Tool is not an end in itself, it is a tool for a purpose. Why care more than just that it fullfills its purpose?
One person's tool is another person's purpose. Design mistakes will cost a lot of extra work in the grand scheme of things. Both for tool writers and for tool users.
Maybe I missunderstood you there. For me your posting sounded like "people should care more about their build system". Now it sounds like "well ist's a fact that people don't care much about their build system". The second is actually what I tried to point out and I think people would care more, if the pain was bigger. Obviously they are more or less happy with their eventually arcane build systems. For me the whole discussion is a little bit overrated. If you like to know my oppinion about build systems: I have used GNU make for very many projects, where portability was not an issue. It is simple and straight forward, gives you all the controll at your fingertips and does what you tell it to do and nothing more. I still like it, but projects where portability is not at least a potential issue become rare for me. For projects where portability was an issue I tried with autotools and neveer really was happy with it (the pain was huge). Actually I prefered to use GNU make and some selfmade scripts to generate the actual makefile for portability issues. Then I came accross CMake. It might not be perfect, but solves the portability issue in an acceptable manner while keeping me in control. I am happy with it and there is no big pain I feel. So there is no need to change it. Yet I am definatelly not a CMake master. I only rarely do bigger changes to the CMake files once a project is set up. Usually I just add new source files or test suites, change some names and that's it. Christof -- okunah gmbh Software nach Maß Werner-Haas-Str. 8 www.okunah.de 86153 Augsburg cd@okunah.de Registergericht Augsburg Geschäftsführer Augsburg HRB 21896 Christof Donat UStID: DE 248 815 055
on Sat May 12 2012, Sergey Popov <loonycyborg-AT-gmail.com> wrote:
On Fri, 11 May 2012 21:56:47 -0600 Dave Abrahams <dave@boostpro.com> wrote:
I think you're not giving CMake enough credit. It has been evolving quite quickly over the past few years. Its programming language may be old and crusty, but it's expressive enough to get the job done. Most importantly, it hits a "sweet spot" between abstract and direct that makes it practical and accessible.
The language isn't the only problem. Remember Makefile generation? It absolutely isn't justified.
It's justified by two things: 1. The fact that it works well in practice 2. The fact that it's compatible with many different environments and usage patterns and with the desire of many programmers to work in an IDE.
Autotools uses this approach only to achieve the cool trick of allowing you to make distribution packages that don't require anything other than standard unix utils to be built. It's just easier to make an unitary build tool than mess around with makefile generation and suffer all limitations of this approach.
I don't notice any particular limitations in CMake projects due to that approach. Do you?
What's so hard about implementing topological sort, anyway?
Not much. But that's a bad way to do things if you want to exploit parallelism. Many small issues like that are why I'd rather let a tool like make handle the job.
Make isn't magic.
All in all, the fact that build tools with such ancient design are still seriously developed is disheartening. Pretty much shows that people don't care much about buildsystems.
I think you've mischaracterized it. Many people care about buildsystems. However, some of us care more about practicality than purity. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Sat, 12 May 2012 06:32:41 -0600 Dave Abrahams <dave@boostpro.com> wrote:
1. The fact that it works well in practice Not really in my experience.
2. The fact that it's compatible with many different environments and usage patterns and with the desire of many programmers to work in an IDE. Generation of projectfiles for IDEs is a different issue altogether. Even with an unitary build tool you still can generate them, though developing IDE plugins is also a possibility.
Autotools uses this approach only to achieve the cool trick of allowing you to make distribution packages that don't require anything other than standard unix utils to be built. It's just easier to make an unitary build tool than mess around with makefile generation and suffer all limitations of this approach.
I don't notice any particular limitations in CMake projects due to that approach. Do you?
Yes. E.g. it's impossible to use any other method of determining whether targets are up-to-date than timestamps and have more abstract targets than files/aliases. Also, the extra step is simply annoying. It doesn't matter that you can hide it with scripts and what-not. It's still there, making your life harder and the overall system more complex. There's just no need for an extra utility just to do topological sort and job scheduling.
What's so hard about implementing topological sort, anyway?
Not much. But that's a bad way to do things if you want to exploit parallelism.
What does this have to do with parallelism? Using Make definitely isn't the only good(if even) way to do parallelism.
on Sat May 12 2012, Sergey Popov <loonycyborg-AT-gmail.com> wrote:
On Sat, 12 May 2012 06:32:41 -0600 Dave Abrahams <dave@boostpro.com> wrote:
1. The fact that it works well in practice Not really in my experience.
2. The fact that it's compatible with many different environments and usage patterns and with the desire of many programmers to work in an IDE. Generation of projectfiles for IDEs is a different issue altogether. Even with an unitary build tool you still can generate them, though developing IDE plugins is also a possibility.
Autotools uses this approach only to achieve the cool trick of allowing you to make distribution packages that don't require anything other than standard unix utils to be built. It's just easier to make an unitary build tool than mess around with makefile generation and suffer all limitations of this approach.
I don't notice any particular limitations in CMake projects due to that approach. Do you?
Yes. E.g. it's impossible to use any other method of determining whether targets are up-to-date than timestamps and have more abstract targets than files/aliases.
I don't know enough about cmake to know whether I should argue with you on these points, but let's stipulate to them. But what kind of job does that prevent you from getting done?
Also, the extra step is simply annoying.
Matter of taste, I guess. It annoys me that Boost.Build does a configure every single time I build.
It doesn't matter that you can hide it with scripts and what-not. It's still there, making your life harder and the overall system more complex.
Seems to simplify things from my POV. Separation of concerns and all that.
There's just no need for an extra utility just to do topological sort and job scheduling.
What's so hard about implementing topological sort, anyway?
Not much. But that's a bad way to do things if you want to exploit parallelism.
What does this have to do with parallelism? Using Make definitely isn't the only good(if even) way to do parallelism.
If you want to build multiple things in parallel, just processing things in toposort order will be slower than exploiting the full graph. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Sat, 12 May 2012 17:08:26 -0600 Dave Abrahams <dave@boostpro.com> wrote:
I don't notice any particular limitations in CMake projects due to that approach. Do you?
Yes. E.g. it's impossible to use any other method of determining whether targets are up-to-date than timestamps and have more abstract targets than files/aliases.
I don't know enough about cmake to know whether I should argue with you on these points, but let's stipulate to them. But what kind of job does that prevent you from getting done? Well.. Using md5 checksums is more robust than Make's timestamp comparisons, I have no idea why would you want to resist progress here :P No point in getting broken builds just because your system clock got screwed or getting a spurious rebuild if a file's timestamp got bumped with no changes to file itself. And scons Value() nodes allow me to very simply generate files from 'thin air', without any file sources. Something absolutely impossible in Make. I know, I tried.
Also, the extra step is simply annoying.
Matter of taste, I guess. It annoys me that Boost.Build does a configure every single time I build. There's no such thing as 'configure'. It just doesn't exist. Those steps should be parts of DAG and bb seems to move in that direction afaict.
It doesn't matter that you can hide it with scripts and what-not. It's still there, making your life harder and the overall system more complex.
Seems to simplify things from my POV. Separation of concerns and all that. Nope. This particular separation happens to be fake. Besides, no sane modern software system's communications are based on generating files for each other. They prefer using apis, either by linking directly or via D-Bus or something. Generating (Make)files is just a hack.
If you want to build multiple things in parallel, just processing things in toposort order will be slower than exploiting the full graph. Sorry. Failed to parse. No idea what point you're making here. Don't see how composite Make-based system would ever have inherent advantage, say, over Waf.
AMDG On 05/13/2012 03:35 AM, Sergey Popov wrote:
If you want to build multiple things in parallel, just processing things in toposort order will be slower than exploiting the full graph. Sorry. Failed to parse. No idea what point you're making here. Don't see how composite Make-based system would ever have inherent advantage, say, over Waf.
topological sort only works if you assume that each task is completed before the next one starts. To run tasks in parallel you have to maintain a queue of tasks that are ready to run and add tasks to it as their dependencies complete. It isn't terribly difficult, but it's more complex than a straight topological sort. In Christ, Steven Watanabe
On Sun, 13 May 2012 06:37:01 -0700 Steven Watanabe <watanabesj@gmail.com> wrote:
topological sort only works if you assume that each task is completed before the next one starts. To run tasks in parallel you have to maintain a queue of tasks that are ready to run and add tasks to it as their dependencies complete. It isn't terribly difficult, but it's more complex than a straight topological sort. If that's the whole point then I apologize for using incorrect and misleading terminology.
on Sun May 13 2012, Sergey Popov <loonycyborg-AT-gmail.com> wrote:
On Sat, 12 May 2012 17:08:26 -0600 Dave Abrahams <dave@boostpro.com> wrote:
I don't notice any particular limitations in CMake projects due to that approach. Do you?
Yes. E.g. it's impossible to use any other method of determining whether targets are up-to-date than timestamps and have more abstract targets than files/aliases.
I don't know enough about cmake to know whether I should argue with you on these points, but let's stipulate to them. But what kind of job does that prevent you from getting done? Well.. Using md5 checksums is more robust than Make's timestamp comparisons, I have no idea why would you want to resist progress here :P
Because it's not a problem in practice, I don't consider it to be a high priority.
Also, the extra step is simply annoying.
Matter of taste, I guess. It annoys me that Boost.Build does a configure every single time I build.
There's no such thing as 'configure'. It just doesn't exist.
It certainly does exist. I wrote a lot of configure code for Boost.Build myself.
It doesn't matter that you can hide it with scripts and what-not. It's still there, making your life harder and the overall system more complex.
Seems to simplify things from my POV. Separation of concerns and all that.
Nope. This particular separation happens to be fake.
Not true. For example, use a Ninja backend with CMake instead of a Make backend: instant speedup! It tells you there's nothing to build in an already-built Boost tree in < 1s on a weak laptop. That wouldn't be possible if the low-level build engine were not a separate component.
Besides, no sane modern software system's communications are based on generating files for each other.
So you don't use C++ compilers, I guess.
They prefer using apis, either by linking directly or via D-Bus or something. Generating (Make)files is just a hack.
It may not be pure, but it works. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Tue, 15 May 2012 06:40:10 -0600 Dave Abrahams <dave@boostpro.com> wrote:
Because it's not a problem in practice, I don't consider it to be a high priority. I've found these features useful and don't wish to forfeit them to someone else's design mistakes.
Also, the extra step is simply annoying.
Matter of taste, I guess. It annoys me that Boost.Build does a configure every single time I build.
There's no such thing as 'configure'. It just doesn't exist.
It certainly does exist. I wrote a lot of configure code for Boost.Build myself.
This nonsensical 'configure' abstraction should go. It only makes build scripts more complex. External dependencies are in fact parts of dependency graph and have no business being segregated into a separate linear script. If you have them in DAG you e.g. won't have to go through C++ checks if you only want documentation to be generated or some other utility task performed. If you'll try to implement that in a linear script you'll just get a bunch of unmaintainable if statements which build tools like Make are supposed to prevent in the first place.
It doesn't matter that you can hide it with scripts and what-not. It's still there, making your life harder and the overall system more complex.
Seems to simplify things from my POV. Separation of concerns and all that.
Nope. This particular separation happens to be fake.
Not true. For example, use a Ninja backend with CMake instead of a Make backend: instant speedup! It tells you there's nothing to build in an already-built Boost tree in < 1s on a weak laptop. That wouldn't be possible if the low-level build engine were not a separate component. This merely seems to fix the problem cmake itself caused. Irrelevant.
Besides, no sane modern software system's communications are based on generating files for each other.
So you don't use C++ compilers, I guess. I use -pipe :P Besides, fixing a build tool is a lot easier than whole goddamn C/C++ toolchain. I wouldn't say that C++ compilers are exactly sane considering you have to use an expert system to build almost any non-trivial program. And the expert system itself is in no obligation to mimic compiler's ways, considering that it can be easily avoided.
They prefer using apis, either by linking directly or via D-Bus or something. Generating (Make)files is just a hack.
It may not be pure, but it works.
The same can be said about Autotools. Do not delude yourself thinking that there exists a dichotomy between purity and practicality. You aim for purity to make the simplest system that accomplishes the task at hand, and there's nothing more practical than that. And making Rube Goldberg machines built from false abstractions is antithesis of practicality.
On 12 May 2012 04:56, Dave Abrahams <dave@boostpro.com> wrote:
on Thu May 10 2012, Beren Minor <beren.minor+boost-AT-gmail.com> wrote:
With CMake and others, as comparison, you are only able to build one variant at a time, and by default everything will be build in conflicting way between build variants (build once in release mode and once in debug mode, and you'll overwrite the previous build output).
Meh; you just use different build directories. This is another one of those advantages of Boost.Build that cost more than they deliver, IMO.
I think you're underestimating this advantage, manually managing build directories could easily become a major chore. Especially during the transition to C++11, as different compilers and libraries have widely varying capabilities.
on Sat May 12 2012, Daniel James <dnljms-AT-gmail.com> wrote:
On 12 May 2012 04:56, Dave Abrahams <dave@boostpro.com> wrote:
on Thu May 10 2012, Beren Minor <beren.minor+boost-AT-gmail.com> wrote:
With CMake and others, as comparison, you are only able to build one variant at a time, and by default everything will be build in conflicting way between build variants (build once in release mode and once in debug mode, and you'll overwrite the previous build output).
Meh; you just use different build directories. This is another one of those advantages of Boost.Build that cost more than they deliver, IMO.
I think you're underestimating this advantage, manually managing build directories could easily become a major chore. Especially during the transition to C++11, as different compilers and libraries have widely varying capabilities.
I don't advocate managing them manually if you have to do this commonly. In fact, it's extremely easy to write a multi-build wrapper script. You can even write it in CMake if you want it to seem like you aren't using a mishmosh of tools. I'm sure we'll do something like that for Boost. My point is that putting that capability near the bottom layer of the build tool leads to nightmares, in my experience. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Sat, May 12, 2012 at 5:56 AM, Dave Abrahams <dave@boostpro.com> wrote:
You mean, in a single build run?
This is exactly the sort of situation where I think the abstraction capabilities you're wishing for are a net loss. It's not that much better to write
lib foo : a.cpp b.cpp : : <link>static <link>shared ;
(or is it <link>static/shared? I forget. And that's part of the problem)
than it is to write
set(sources a.cpp b.cpp) add_library(foo STATIC ${sources}) add_library(foo SHARED ${sources})
and the latter one matches up really well with what users understand. Furthermore, anyone who wants to build a library both ways with less boilerplate can write a simple function that does it.
Except that not all variants should be build on all platforms. Linux (probably) doesn't need the static ones. And on Windows you're missing the static runtime one. Your rules don't appear to take care of variant naming either. Olaf
on Sat May 12 2012, Olaf van der Spek <ml-AT-vdspek.org> wrote:
On Sat, May 12, 2012 at 5:56 AM, Dave Abrahams <dave@boostpro.com> wrote:
You mean, in a single build run?
This is exactly the sort of situation where I think the abstraction capabilities you're wishing for are a net loss. It's not that much better to write
lib foo : a.cpp b.cpp : : <link>static <link>shared ;
(or is it <link>static/shared? I forget. And that's part of the problem)
than it is to write
set(sources a.cpp b.cpp) add_library(foo STATIC ${sources}) add_library(foo SHARED ${sources})
and the latter one matches up really well with what users understand. Furthermore, anyone who wants to build a library both ways with less boilerplate can write a simple function that does it.
Except that not all variants should be build on all platforms. Linux (probably) doesn't need the static ones. And on Windows you're missing the static runtime one.
Your rules don't appear to take care of variant naming either.
Right. And 90% of use-cases don't want to take care of any of those things. That's why we wrote the rules as we did. Generating all the possible variants of a library is a packager's job, not part of the regular development workflow nor something that users regularly want. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Mon, May 14, 2012 at 9:36 AM, Dave Abrahams <dave@boostpro.com> wrote:
Except that not all variants should be build on all platforms. Linux (probably) doesn't need the static ones. And on Windows you're missing the static runtime one.
Your rules don't appear to take care of variant naming either.
Right. And 90% of use-cases don't want to take care of any of those things. That's why we wrote the rules as we did. Generating all the possible variants of a library is a packager's job, not part of the regular development workflow nor something that users regularly want.
Right, that's my point. It'd be nice if CMake (upstream) supported this, then other C++ libs would benefit from it too. -- Olaf
on Tue May 15 2012, Olaf van der Spek <ml-AT-vdspek.org> wrote:
On Mon, May 14, 2012 at 9:36 AM, Dave Abrahams <dave@boostpro.com> wrote:
Except that not all variants should be build on all platforms. Linux (probably) doesn't need the static ones. And on Windows you're missing the static runtime one.
Your rules don't appear to take care of variant naming either.
Right. And 90% of use-cases don't want to take care of any of those things. That's why we wrote the rules as we did. Generating all the possible variants of a library is a packager's job, not part of the regular development workflow nor something that users regularly want.
Right, that's my point. It'd be nice if CMake (upstream) supported this, then other C++ libs would benefit from it too.
Agreed. I hope that CMake (upstream) will take about half the work we do for CMake support in ryppl. If you'd like to code up support for this, we'd welcome your contribution. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 5/14/2012 2:36 AM, Dave Abrahams wrote:
Right. And 90% of use-cases don't want to take care of any of those things. That's why we wrote the rules as we did. Generating all the possible variants of a library is a packager's job, not part of the regular development workflow nor something that users regularly want.
If multiple library variants are desired to be supported, then it shouldn't just be part of the regular development workflow, it should be part of continuous integration. Boost.Build makes it much easier for me to create various build configurations targeting the different variants without cluttering the build files. For an application that only cares about building one way, the extra abstraction isn't so useful, I agree. For libraries, it's very useful. -Matt
on Tue May 15 2012, Matthew Chambers <matt.chambers42-AT-gmail.com> wrote:
On 5/14/2012 2:36 AM, Dave Abrahams wrote:
Right. And 90% of use-cases don't want to take care of any of those things. That's why we wrote the rules as we did. Generating all the possible variants of a library is a packager's job, not part of the regular development workflow nor something that users regularly want.
If multiple library variants are desired to be supported, then it shouldn't just be part of the regular development workflow, it should be part of continuous integration.
Strike "just," and I agree with you. Most CI should go on somewhere away from the average developer's machine, although it's always good to be able to duplicate that procedure locally.
Boost.Build makes it much easier for me to create various build configurations targeting the different variants without cluttering the build files.
Right. And Ryppl is going going to add what's necessary in a layer on top of cmake. In fact, this would be a good time to find out what it is that you need so that we can implement it in the Ryppl build tool.
For an application that only cares about building one way, the extra abstraction isn't so useful, I agree. For libraries, it's very useful.
Why should "building-many-ways" be more of a concern for libraries than for applications? -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Mon, May 21, 2012 at 6:47 PM, Dave Abrahams <dave@boostpro.com> wrote:
For an application that only cares about building one way, the extra abstraction isn't so useful, I agree. For libraries, it's very useful.
Why should "building-many-ways" be more of a concern for libraries than for applications?
Because for apps it's less of an issue. Typically you only build debug and release variants. Although some might want to build for both x86 and x64 now. -- Olaf
On Mon, May 21, 2012 at 12:47 PM, Dave Abrahams <dave@boostpro.com> wrote:
on Tue May 15 2012, Matthew Chambers <matt.chambers42-AT-gmail.com> wrote:
On 5/14/2012 2:36 AM, Dave Abrahams wrote:
Right. And 90% of use-cases don't want to take care of any of those things. That's why we wrote the rules as we did. Generating all the possible variants of a library is a packager's job, not part of the regular development workflow nor something that users regularly want.
If multiple library variants are desired to be supported, then it shouldn't just be part of the regular development workflow, it should be part of continuous integration.
Strike "just," and I agree with you. Most CI should go on somewhere away from the average developer's machine, although it's always good to be able to duplicate that procedure locally.
My own local workflow is to develop via IDE (Visual Studio latest production release) and then when those tests pass, kick off bjam against many compilers (currently 7). For Filesystem, some of the tests are static, some are shared. I really should test both debug and release builds, although I'm not doing that now. I prefer results to be reported via an HTML table, but am willing to write the program to generate that HTML page, as long as the test results are available in some easy to parse form.
Boost.Build makes it much easier for me to create various build configurations targeting the different variants without cluttering the build files.
Right. And Ryppl is going going to add what's necessary in a layer on top of cmake. In fact, this would be a good time to find out what it is that you need so that we can implement it in the Ryppl build tool.
For me, it is pretty much what bjam does now. Such as being able to specify: * Test specs invoke build specs if needed. * Compile, link, or run test, where pass|fail can be a report of no errors or errors. * Define macros, globally, per test, or per platform. * Define compiler or linker switches, globally, per test, or per platform. * Specify macros, switches, or other config details based on static, shared, debug, or release builds. * Be able to add or override macros, switches, or other config details from the command line. * Be able to add or override macros, switches, or other config details from a user config file. Presumably CMake already handles most of that. --Beman
I almost agree. When it comes to build system it is oftentimes better to be more verbose and less elegant, because it is easier for the user to maintain the build system code. And also, being less abstract, more low-level is often desirable, as users do want to control various platform-specific details of the build process. But there are also time they are not! So I guess, there should be some sound abstraction level. Also, I need to notice, being meta-build system has its disatvantages: 1. Requires extra step. This matters, because you need to remember arguments tools, manage files, env. vars etc. 2. The meta-build system could not do more than a build system. See, you can add fancy pre- and post- build rules to visual studio, but the logic of how this rules are invoked are determined by the build system, not the meta-build one. 3. Synchronization between the two might be annoying, for example, regenerating Visual Studio solution, while it is opened in IDE; understanding build system files are temporaries and should not be checked in the source control and so on. On the other hand, as somebody mentioned, good IDE should be interoperable w/ any reasonable build-system, however, in practice this is oftentimes not the case, so meta-build comes handy. On Sat, May 12, 2012 at 6:56 AM, Dave Abrahams <dave@boostpro.com> wrote:
on Thu May 10 2012, Beren Minor <beren.minor+boost-AT-gmail.com> wrote:
Hi,
My 2 cents regarding build systems as I've recently had to write a build framework using CMake and as I use Boost.Build for personal projects.
I think Boost.Build and CMake are at a totally different level of abstraction: CMake is low-level when Boost.Build is high-level. For comparison with other build systems, Make, SCons are at the same level as CMake. Premake is probably closer to Boost.Build (I don't know enough others but there's not a lot being as high-level as BBv2).
One of the problems people have with Boost.Build is that its high-level abstractions make it hard to control. There's so much going on between the code you write in your Jamfile and the actual command-lines that come out the other end, that it can be hard to know how to get the effect you want. If you need to do something specific for a given platform or compiler, you can't use a simple if/then statement based on some variable; you have to use a creatively-defined declarative language, and hope that the Boost.Build engine makes the choices you intend. I was a major participant in the design of that language, and in principle I think a declarative approach is ideal, but I now accept that the language we have doesn't match up well with the way that most users of the build system think, and that the high level of abstraction is not a net win.
Parts of Boost.Build are an elegant design, no doubt. When Troy and Doug started talking up CMake to me, I kept pushing them to implement more of the abstractions in Boost.Build. But I've come to see that many of them aren't needed. Boost is a pretty good test case for complexity, and the CMake files for building boost portably (https://github.com/ryppl/boost-zero/tree/master/cmake) are not especially more complicated than its Jamfiles. But there's an order of magnitude more code in Boost.Build than there is in Ryppl's CMake support (https://github.com/ryppl/ryppl/tree/develop/cmake/Modules).
Of course SCons and CMake still have a major advantage over Make because of their portability. But they offer a very little abstraction over simple Make. Surely, there are some built-in rules to easily create shared/static libraries or executables, but you still have to define a lot of things manually. As an example, I quickly realized that CMake is simply unable to create both shared and static version of a library if you don't explicitly write the two rules to build them.
You mean, in a single build run?
This is exactly the sort of situation where I think the abstraction capabilities you're wishing for are a net loss. It's not that much better to write
lib foo : a.cpp b.cpp : : <link>static <link>shared ;
(or is it <link>static/shared? I forget. And that's part of the problem)
than it is to write
set(sources a.cpp b.cpp) add_library(foo STATIC ${sources}) add_library(foo SHARED ${sources})
and the latter one matches up really well with what users understand. Furthermore, anyone who wants to build a library both ways with less boilerplate can write a simple function that does it.
For comparison, with Boost.Build, creating a library is as simple as writing: lib foo : bar.c ;
Then, depending in which context the library is used, BBv2 will create shared or static or both versions of the library. You don't have to care about the details, you'll have automatic resolution of what is required to satisfy the build request, based on the build condition you asked for.
...until it surprises you, as in https://trac.lvk.cs.msu.su/boost.build/wiki/AlternativeSelection Sometimes it's better to be a little more verbose and a little less automatic.
The abstraction level of Boost.Build is also very visible when you start working on multiple compiler and/or multiple build variants. As long as you don't need fancy compiler flags (and I think most projects shouldn't play with fancy compiler flags) you can trust Boost.Build to abstract all the details of the compiler flags and to offer you the possibility to build everything you want, at once.
With CMake and others, as comparison, you are only able to build one variant at a time, and by default everything will be build in conflicting way between build variants (build once in release mode and once in debug mode, and you'll overwrite the previous build output).
Meh; you just use different build directories. This is another one of those advantages of Boost.Build that cost more than they deliver, IMO. It means that every Boost.Build target is actually a meta-target representing one or more real targets, which complexity makes the whole system harder to understand and control... and, especially, harder to extend.
As said, you can use different build folders for different variants, but that's much less easy to use and not very maintainable unless you maintain a wrapper around the build system that does this for you.
The advantage of maintaining a thin wrapper over the build system, if you need this kind of thing regularly, is that it's easy to get in underneath this layer and work with the build system directly: to experiment, extend, whatever. And at that level, you're just dealing with a single target and build variant. In the case of Boost.Build, there's no way to separate anything from the possibility of multiple variants, compilers, etc. In the end, most users of the build system don't need to do multiple builds at once anyway, so they never see the wrapper and never even have to deal with that incremental increase in complexity.
I like very much Boost.Build, and I was quite disappointed to hear that there's a plan to move Boost to CMake. Boost is the main user of Boost.Build and I'm a little bit afraid of seeing it disappear, or being less and less unsupported. Even if I perfectly understand the reason of this change: Boost.Build suffers from lack of documentation and lack of popularity, whereas CMake is very well documented and widely used, it leaves me a bitter taste in mouth.
I don't know that the change will happen, but I hope very much that it will. I'm sorry for the bitter taste and for the hurt feelings of those who have invested so much in Boost.Build. However, my priority has to be on what's best for Boost's mission as a vehicle for C++ libraries.
From a personal point of view, Boost.Build (even if not perfect as it is) does what a build system should do: abstract the user all the detail on how the objects will be built and let him only care about the high-level objects and their relations.
The problem with that approach is that when something breaks, you usually end up working backwards from the actual command-lines you need the system to issue, and if the connection between the build description files and those command-lines is too distant, it can be hard to make the leap.
CMake and others are "old-generation" build systems, which may be used as building blocks to achieve this goal.
I think you're not giving CMake enough credit. It has been evolving quite quickly over the past few years. Its programming language may be old and crusty, but it's expressive enough to get the job done. Most importantly, it hits a "sweet spot" between abstract and direct that makes it practical and accessible.
-- Dave Abrahams BoostPro Computing http://www.boostpro.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Daniel Krikun
on Tue May 15 2012, Daniel Krikun <krikun.daniel-AT-gmail.com> wrote:
I almost agree. When it comes to build system it is oftentimes better to be more verbose and less elegant, because it is easier for the user to maintain the build system code. And also, being less abstract, more low-level is often desirable, as users do want to control various platform-specific details of the build process. But there are also time they are not! So I guess, there should be some sound abstraction level.
Yes, exactly. Abstraction needs to strike the right balance. We have been trying to do that very carefully with Ryppl and CMake. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Hi, Other interesting build systems to look at: fast but not complete: http://gittup.org/tup/ Lua frontend for cmake: http://www.cmake.org/Wiki/CMake:Experiments_With_Lua regards Andreas
On 09/05/12 02:54, Nathan Ridge wrote:
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).
For all I know, this is merely a marketing trick employed by vocal CMake proponents. - Volodya
participants (26)
-
Allan Johns -
Andreas Pokorny -
Artyom Beilis -
Beman Dawes -
Beren Minor -
Bjørn Roald -
Boris Schaeling -
Christof Donat -
Daniel James -
Daniel Krikun -
Dave Abrahams -
Francois Duranleau -
Ivan Le Lann -
james -
Jeffrey Lee Hellrung, Jr. -
Klaim - Joël Lamotte -
Marshall Clow -
Matthew Chambers -
Nathan Ridge -
Neal Becker -
Olaf van der Spek -
Robert Ramey -
Sergey Popov -
Steven Watanabe -
Tim Blechmann -
Vladimir Prus