Hey everyone, Is there a reason why Boost uses Boost.Jam/Boost.Build for reasons other than tradition? Does it have advantages over other build systems, in particular CMake (which I consider to be its main competitor)? Are there many people/projects who use Boost.Jam/Boost.Build outside of Boost? These questions are asked purely out of curiosity due to my ignorance of Boost.Jam/Boost.Build, not because I have an axe to grind. Cheers, Greg
On 03/26/2011 04:08 PM, Gregory Crosswhite wrote:
Hey everyone,
Is there a reason why Boost uses Boost.Jam/Boost.Build for reasons other than tradition?
Boost.Build works great for those around here caring enough to maintain a build system for boost. Also it seams to work well enough that a new build system is not a top priority for people willing to do something about it. That said I think the fact that it is not as common and well known as some alternatives, and that it is missing some features people are expecting causes people to ask for CMake.
Does it have advantages over other build systems, in particular CMake (which I consider to be its main competitor)?
CMake is not a build system. CMake is a meta build system tool that takes a platform independent meta description of a build system and generate your platform specific build systems based on it. It seems CMake or CMake scripts needs a fair bit of tweaks to replace Boost.Build. Trying to make a Boost.Build killer out of CMake has taken years by some dedicated people around here, and they are clearly not done.
Are there many people/projects who use Boost.Jam/Boost.Build outside of Boost?
I have no idea, but there are some that enjoy its features - yes.
These questions are asked purely out of curiosity due to my ignorance of Boost.Jam/Boost.Build, not because I have an axe to grind.
In my opinion, I would like to see efforts to make boost build generate CMake scripts and/or visa versa. -- Bjørn
Thanks, Bjørn! - Greg On 3/26/11 1:29 PM, Bjørn Roald wrote:
On 03/26/2011 04:08 PM, Gregory Crosswhite wrote:
Hey everyone,
Is there a reason why Boost uses Boost.Jam/Boost.Build for reasons other than tradition?
Boost.Build works great for those around here caring enough to maintain a build system for boost. Also it seams to work well enough that a new build system is not a top priority for people willing to do something about it. That said I think the fact that it is not as common and well known as some alternatives, and that it is missing some features people are expecting causes people to ask for CMake.
Does it have advantages over other build systems, in particular CMake (which I consider to be its main competitor)?
CMake is not a build system. CMake is a meta build system tool that takes a platform independent meta description of a build system and generate your platform specific build systems based on it. It seems CMake or CMake scripts needs a fair bit of tweaks to replace Boost.Build. Trying to make a Boost.Build killer out of CMake has taken years by some dedicated people around here, and they are clearly not done.
Are there many people/projects who use Boost.Jam/Boost.Build outside of Boost?
I have no idea, but there are some that enjoy its features - yes.
These questions are asked purely out of curiosity due to my ignorance of Boost.Jam/Boost.Build, not because I have an axe to grind.
In my opinion, I would like to see efforts to make boost build generate CMake scripts and/or visa versa.
Is there a reason why Boost uses Boost.Jam/Boost.Build for reasons other
than tradition?
Boost.Build works great for those around here caring enough to maintain a build system for boost.
In other words it work for thous who: 1. Maintain the system 2. Already has BBv2 support (existing Boost.Lobraries).
Also it seams to work well enough that a new build system is not a top priority for people willing to do something about it. That said I think the fact that it is not as common and well known as some alternatives, and that it is missing some features people are expecting causes people to ask for CMake.
If fact BBv2 is total nightmare. It took me 3 work days to make unit-tests work for Boost.Locale using BBv2 and I had to add a workaround changing the test sources itself. 1. Documentation is just missing. 2. Half of functionality Boost.Locale uses for build is undocumented and works only because it was originally written by Vladimir Prus. And this is by-the-way after several patches applied to it in trunk. 3. Simple tasks that every normal build system supports undocumented and unclear (search library for example) BBv2 works for Boost because it exists for many years. But still every time people ask for replacement.
Does it have advantages over other build systems, in particular CMake (which I consider to be its main competitor)?
CMake is not a build system. CMake is a meta build system tool that takes a platform independent meta description of a build system and generate your platform specific build systems based on it.
In fact CMake is full featured and mature build system that provides what build system should, it does not matter if it creates makefiles or runs the compiler by itself, the fact is that it works, well documented and full-featured. It is not perfect but it is much easier and transparent to use in comparison with BB. To make it more clear: How many big projects use CMake... Numerous including famous ones like KDE How many big projects use Boost.Build. Hmmmm... One - Boost.
Are there many people/projects who use Boost.Jam/Boost.Build outside of Boost?
I have no idea, but there are some that enjoy its features - yes.
Almost nobody... And many-many complain about it.
These questions are asked purely out of curiosity due to my ignorance of Boost.Jam/Boost.Build, not because I have an axe to grind.
In my opinion, I would like to see efforts to make boost build generate CMake scripts and/or visa versa.
I hope someday BB would be replaced with CMake, but as everything else it requires time and effort (=money) so BBv2 still lives. But to be honest poor guys thous who would try to make complex builds with BBv2. I understand that BBv2 has its strong side but as a tool that was developed for boost and not for wide range of project it is very limited for everything that goes outside the box, and even when it supports required features there is no documentation exists as every Boost sub-project implemented this by consulting on mailing lists. So no normal and usable documentation exists. Please don't take me wrong. I understand that is it much easier to criticize the system then provide a solution, but as time passes and more libraries go into Boost and as libraries become more complicated, the requirements from BB become higher... And to be honest I don't know if anybody but Vladimir Prus knows how to solve them. And he does not always have a time to help. Artyom
On 03/26/2011 10:03 PM, Artyom wrote:
Is there a reason why Boost uses Boost.Jam/Boost.Build for reasons other than tradition?
Boost.Build works great for those around here caring enough to maintain a build system for boost. In other words it work for thous who:
1. Maintain the system 2. Already has BBv2 support (existing Boost.Lobraries).
I think this is the case, yes.
Also it seams to work well enough that a new build system is not a top priority for people willing to do something about it. That said I think the fact that it is not as common and well known as some alternatives, and that it is missing some features people are expecting causes people to ask for CMake.
If fact BBv2 is total nightmare.
wow...
It took me 3 work days to make unit-tests work for Boost.Locale using BBv2 and I had to add a workaround changing the test sources itself.
I have used a few build systems, and they have all required a bit of learning. I do not think Boost.Build is exceptional in that it is much harder to learn or use than others. A more relevant question is if we can get away with less required learning by using an alternative system. Hopefully a system that is both simpler to learn and a system more people know before they are introduced to boost. That system may or may not be based on CMake, I do not know.
1. Documentation is just missing.
I guess you mean "lacking"! If not - have you looked or asked for documentation at all? I do not think your statement is fair. Google showed me the way here: http://www.boost.org/boost-build2 in less than 10 seconds. Also, the boost getting started guide has a pointer: http://www.boost.org/doc/libs/1_46_1/tools/build/v2/index.html for users that desire to build from source and need more than the standard bootstrap that is suggested before you even need to look at the docs. And there is a boost.build link in the documentation section on the boost website.
2. Half of functionality Boost.Locale uses for build is undocumented
I thought you just said nothing was documented, so this statement a bit surprising. I guess you have read some documentation after all ;-)
and works only because it was originally written by Vladimir Prus.
And this is by-the-way after several patches applied to it in trunk.
3. Simple tasks that every normal build system supports undocumented and unclear (search library for example)
I do not know exactly what you are referring to, but I find quite a bit about searching for libraries in the docs. This may be new material though, or unrelated to what you refer to. My experience is that most build systems have undocumented or experimental features, that is nothing special with Boost.Build. I have never worked on a CMake based build system other that toying with it. Its documentation may or may not be very good, I do not know.
BBv2 works for Boost because it exists for many years. But still every time people ask for replacement.
Sure - people ask for replacement. My worry is that few of those asking are willing to do the work. In addition, it does not help that announced replacements are abandoned or the people involved constantly divert to grander ideas, if nothing useful materialize. I suspect most people asking for replacement just want something they know how to manage, something they already know how to use. That is a fair thing to ask for, but not necessarily a simple thing to do in a way pleasing many or all. Meta build systems like CMake does however provide a possible solution to some of this, but some things also get more complicated. The four meta build system tools I have tried express the projects with the same basic concepts, but with very different syntax. The next great thing after CMake will most likely invent their own language. Commonality of the scripting for the developer is lost. Note also that some regular build tools, like Boost.Build, uses similar abstract syntax. In Boost.Build some of the meta concepts for software projects are used in project descriptions. One example is dependencies on other projects, not their artifacts. As with the meta tools - Boost.Build share no project description language with other tools :-( What is needed is a unified build system description language. This language should provide high level description of software projects and their dependencies and build based on conventions. I think such a language would be a great idea if tools could comply to it.
Does it have advantages over other build systems, in particular CMake (which I consider to be its main competitor)? CMake is not a build system. CMake is a meta build system tool that takes a platform independent meta description of a build system and generate your platform specific build systems based on it. In fact CMake is full featured and mature build system that provides what build system should, it does not matter if it creates makefiles or runs the compiler by itself, the fact is that it works, well documented and full-featured.
I did not try to make an argument against CMake or meta build systems in general. The fact that it has the ability to create build systems native to your platform, and then also be compatible with most IDEs is a big plus. My point is that CMake out of the box does not build boost, build tests, run tests, build documentation, and so on. Whether all of this should be the task of the build system is a question that may be asked, but I think it needs to be done by whatever it is that replaces boost build in the future.
It is not perfect but it is much easier and transparent to use in comparison with BB.
Sure, still nobody has up to now been able to make and maintain a CMake based system for boost.
To make it more clear:
How many big projects use CMake... Numerous including famous ones like KDE How many big projects use Boost.Build. Hmmmm... One - Boost.
Not all projects are open source.
Are there many people/projects who use Boost.Jam/Boost.Build outside of
Boost?
I have no idea, but there are some that enjoy its features - yes.
Almost nobody... And many-many complain about it.
Either these statements contradict each other, or BBv2 must be very very bad. I can just not see how it is that bad.
These questions are asked purely out of curiosity due to my ignorance of Boost.Jam/Boost.Build, not because I have an axe to grind. In my opinion, I would like to see efforts to make boost build generate CMake scripts and/or visa versa.
I hope someday BB would be replaced with CMake, but as everything else it requires time and effort (=money) so BBv2 still lives.
But to be honest poor guys thous who would try to make complex builds with BBv2.
I understand that BBv2 has its strong side but as a tool that was developed for boost and not for wide range of project it is very limited for everything that goes outside the box, and even when it supports required features there is no documentation exists as every Boost sub-project implemented this by consulting on mailing lists.
So no normal and usable documentation exists.
Please don't take me wrong. I understand that is it much easier to criticize the system then provide a solution, but as time passes and more libraries go into Boost and as libraries become more complicated, the requirements from BB become higher... And to be honest I don't know if anybody but Vladimir Prus knows how to solve them.
And he does not always have a time to help.
Dependence on individuals is always a real concern, I agree. But I am not sure that is a real issue here. -- Bjørn
Artyom wrote:
These questions are asked purely out of curiosity due to my ignorance of Boost.Jam/Boost.Build, not because I have an axe to grind.
In my opinion, I would like to see efforts to make boost build generate CMake scripts and/or visa versa.
I hope someday BB would be replaced with CMake, but as everything else it requires time and effort (=money) so BBv2 still lives.
Quite a lof ot effort went into CMake experiements, including: - Writing a pile of CMake code to do what Boost.Build does now, similar in #lines to Boost.Build. - Employing folks (supposedly for real $) to work on ryppl. - Supposedly paying money to Kitware for some CMake improvements. And, it's still not there yet (after over 2 years). Frankly, if somebody wants to have an ideal build system for Boost, and for C++ projects in general, it would be better to invest a similar amount of person-hours and dollars into Boost.Build -- and have the result ready already. - Volodya -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40
[Lots of prior discussion]
I consider myself an outsider to this discussion because I never used CMake, but I would like to point out that there are also people (like me) that really like Boost.Build. I /can/ compare it with SCons (and classic Make), and I like it better because of the cleaner syntax and the easy cross-compiler configuration. Learning the basics took me at most an hour. In fact it's not totally unlikely that I will use it for all my future projects. -Julian
On 27/03/2011 11:10, Vladimir Prus wrote:
Artyom wrote:
These questions are asked purely out of curiosity due to my ignorance of Boost.Jam/Boost.Build, not because I have an axe to grind.
In my opinion, I would like to see efforts to make boost build generate CMake scripts and/or visa versa.
I hope someday BB would be replaced with CMake, but as everything else it requires time and effort (=money) so BBv2 still lives.
Quite a lof ot effort went into CMake experiements, including:
- Writing a pile of CMake code to do what Boost.Build does now, similar in #lines to Boost.Build. - Employing folks (supposedly for real $) to work on ryppl. - Supposedly paying money to Kitware for some CMake improvements.
And, it's still not there yet (after over 2 years).
I believe that is inaccurate. Ryppl is not ready because it tries to do a lot of things at once, some of which are non-trivial. But porting the current Boost to CMake has already been done, and works well to a point. It also does much more than what Boost.Build does now.
Mathias Gaunard wrote:
On 27/03/2011 11:10, Vladimir Prus wrote:
Artyom wrote:
These questions are asked purely out of curiosity due to my ignorance of Boost.Jam/Boost.Build, not because I have an axe to grind.
In my opinion, I would like to see efforts to make boost build generate CMake scripts and/or visa versa.
I hope someday BB would be replaced with CMake, but as everything else it requires time and effort (=money) so BBv2 still lives.
Quite a lof ot effort went into CMake experiements, including:
- Writing a pile of CMake code to do what Boost.Build does now, similar in #lines to Boost.Build. - Employing folks (supposedly for real $) to work on ryppl. - Supposedly paying money to Kitware for some CMake improvements.
And, it's still not there yet (after over 2 years).
I believe that is inaccurate.
Ryppl is not ready because it tries to do a lot of things at once, some of which are non-trivial.
But porting the current Boost to CMake has already been done, and works well to a point.
It surely depends on what "point" is. There's more to it than making "cmake + make" exit with non-zero status. - Volodya -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40
On 3/26/2011 5:03 PM, Artyom wrote:
Is there a reason why Boost uses Boost.Jam/Boost.Build for reasons other
than tradition?
Boost.Build works great for those around here caring enough to maintain a build system for boost.
In other words it work for thous who:
1. Maintain the system 2. Already has BBv2 support (existing Boost.Lobraries).
Also it seams to work well enough that a new build system is not a top priority for people willing to do something about it. That said I think the fact that it is not as common and well known as some alternatives, and that it is missing some features people are expecting causes people to ask for CMake.
If fact BBv2 is total nightmare.
It took me 3 work days to make unit-tests work for Boost.Locale using BBv2 and I had to add a workaround changing the test sources itself.
1. Documentation is just missing.
2. Half of functionality Boost.Locale uses for build is undocumented and works only because it was originally written by Vladimir Prus.
And this is by-the-way after several patches applied to it in trunk.
3. Simple tasks that every normal build system supports undocumented and unclear (search library for example)
It's the documentation, not the tool itself, which is really difficult and makes Boost Build a nightmare for you. The functionality in Boost Build is very adequate and often very good. The documentation is generally poor because it does not attempt to explain all of the information in Boost Build, and what it does explain is spread out in many different areas of the documentation to the detriment of the documentation's organization. Finally, what passes for an index in the documentation indexes practically nothing and is essentially completely worthless. Added to this is that what is presented online is almost never up to date with the latest changes in the documentation, and one has a nightmare produced not by bad software but more by an attitude about the lack of importance of the documentation in actually using the system. Your comment is shooting the messenger because you don't understand the message. The message, Boost Build itself, is very neat software. The messenger, the documentation, makes it very hard to understand the message because it is not organized in a thorough way, and that makes it very hard to use the software itself except if you already know a great, great deal. When software is very good, but very complicated, it is often hard to get developers to realize that it is to their interest to explain the software as methodically and as thoroughly as they should. They often resent it because they have produced this wonderful software system which they understand, and worked very hard on, and they can not understand why others should not understand it as well as they do with the explanation they produce to suit their own needs. I honestly believe this is the mindset into which the developers of Boost Build have settled. The system itself is wonderful, and does a tremendous number of things automatically for the developer, but when the developer needs to do something outside the normal way the Boost Build system operates, it is next to impossible finding this information in the documentation, because so much is missing or just assumes that the programmer should somehow know. So I would say to you that your troubles with Boost Build are the same as my troubles with it have been periodically and those of so many Boost developers, which is not the software itself, which works wonderfully, but with understanding how to do things with the system for which the documentation simply does not provide answers or even adequate explanations. I do not have an answer for this because, like you, I am not really interested in writing the Boost Build documentation for the developers just to use the system. When I am stumped, I ask on the Boost Build mailing list, get my answer, then move on to the next time I am stumped using the system. This is not the way I like to develop but "it is what it is". But I do understand your frustration.
Edward Diener wrote:
The documentation is generally poor because it does not attempt to explain all of the information in Boost Build, and what it does explain is spread out in many different areas of the documentation to the detriment of the documentation's organization. Finally, what passes for an index in the documentation indexes practically nothing and is essentially completely worthless.
I think it would be great if somebody who knows how to write documentation could write some guidelines how to produce usable index. Every time I think about adding anything, I am not even sure what should be primary index term, and what should be secondary ;-) - Volodya -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40
Edward Diener wrote:
The documentation is generally poor because it does not attempt to explain all of the information in Boost Build, and what it does explain is spread out in many different areas of the documentation to the detriment of the documentation's organization. Finally, what passes for an index in the documentation indexes practically nothing and is essentially completely worthless.
I think it would be great if somebody who knows how to write documentation could write some guidelines how to produce usable index. Every time I think about adding anything, I am not even sure what should be primary index term, and what should be secondary ;-)
- Volodya
Volodya, I think you should write the documentation as you write it for any software or library. 1. General Concepts: a) Syntax b) Rules etc. 2. Tutorial How to do common stuff: a) Build a program b) Build a library c) Build a test d) Configure things conditionally e) Create extensions And so on. Pass on common features of Autotools, CMake, SCons and make sure users can easily figure out how to do. 3. **Full** reference documentation: - Properties - Modules - Rules And so on. This is even more important then tutorial because user and search for specific functions rules if they documented but he can't if there is no docs. As example I can provide ICU, their tutorials are very poor and basic but their reference docs are really great. And given a fact that 1 and 2 mostly exists you should work on 3rd part. Also I may ask is there a chance to connect Doxygen with BBv2? It may make this task much easier. Artyom
On 3/27/2011 3:02 PM, Artyom wrote:
Edward Diener wrote:
The documentation is generally poor because it does not attempt to explain all of the information in Boost Build, and what it does explain is spread out in many different areas of the documentation to the detriment of the documentation's organization. Finally, what passes for an index in the documentation indexes practically nothing and is essentially completely worthless.
I think it would be great if somebody who knows how to write documentation could write some guidelines how to produce usable index. Every time I think about adding anything, I am not even sure what should be primary index term, and what should be secondary ;-)
- Volodya
Volodya,
I think you should write the documentation as you write it for any software or library.
Thanks for the suggestion.. <https://svn.boost.org/trac/boost/ticket/5391>. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
At Sun, 27 Mar 2011 11:34:43 -0400, Edward Diener wrote:
When software is very good, but very complicated, it is often hard to get developers to realize that it is to their interest to explain the software as methodically and as thoroughly as they should.
Yes, but there is an alternative: simpler software (where one element of simplicity is similarity to, and a foundation of, tools and paradigms with which many people are already familiar).
They often resent it because they have produced this wonderful software system which they understand, and worked very hard on, and they can not understand why others should not understand it as well as they do with the explanation they produce to suit their own needs. I honestly believe this is the mindset into which the developers of Boost Build have settled. The system itself is wonderful, and does a tremendous number of things automatically for the developer, but when the developer needs to do something outside the normal way the Boost Build system operates, it is next to impossible finding this information in the documentation, because so much is missing or just assumes that the programmer should somehow know.
Part of that is because the design tries to do too much. Specifically, the production of multiple build configurations with a single build command offers most users no benefit in exchange for the enormous complication it causes in design, implementation, and especially in writing build instructions (Jamfiles in our case). For the few who do benefit from the feature, the ability to build multiple configurations easily could have been written as another layer that invokes the build system multiple times. The design made this tradeoff because it was primarily trying to serve developers and testers of Boost libraries on multiple toolsets. That turns out to not be the primary audience of our build system, since users end up having to deal with it---but even if that were the primary audience, I doubt that scaling the steep learning curve would be worth the benefit overall. Just so it's clear I'm not blaming anyone else: these problems are as much due to my own shortsightedness as to anything else. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Tue, Mar 29, 2011 at 5:04 PM, Dave Abrahams <dave@boostpro.com> wrote:
At Sun, 27 Mar 2011 11:34:43 -0400, Edward Diener wrote:
When software is very good, but very complicated, it is often hard to get developers to realize that it is to their interest to explain the software as methodically and as thoroughly as they should.
Yes, but there is an alternative: simpler software (where one element of simplicity is similarity to, and a foundation of, tools and paradigms with which many people are already familiar).
They often resent it because they have produced this wonderful software system which they understand, and worked very hard on, and they can not understand why others should not understand it as well as they do with the explanation they produce to suit their own needs. I honestly believe this is the mindset into which the developers of Boost Build have settled. The system itself is wonderful, and does a tremendous number of things automatically for the developer, but when the developer needs to do something outside the normal way the Boost Build system operates, it is next to impossible finding this information in the documentation, because so much is missing or just assumes that the programmer should somehow know.
Part of that is because the design tries to do too much.
I actually don't think that the design is overly complicated. Creating a build script that works on many different platforms is not a simple problem (if you don't need a portable build script, there are many simpler solutions, for example it only takes a couple of minutes to throw the Boost Thread cpp files in a Visual Studio project if you need to use boost.thread on Windows.) My only problem with Boost Build is that it is oh so slow. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
At Tue, 29 Mar 2011 17:15:31 -0700, Emil Dotchevski wrote:
I actually don't think that the design is overly complicated. Creating a build script that works on many different platforms is not a simple problem
You don't need to tell me that; I'm the originator of the BB design and had a lot to do with the design foundations of BBv2. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Mar 29, 2011 7:05 PM, "Dave Abrahams" <dave@boostpro.com> wrote:
Part of that is because the design tries to do too much. Specifically, the production of multiple build configurations with a single build command offers most users no benefit in exchange for the enormous complication it causes in design, implementation, and especially in writing build instructions (Jamfiles in our case). For the few who do benefit from the feature, the ability to build multiple configurations easily could have been written as another layer that invokes the build system multiple times.
I'm not a BB expert, but it seems to me that the ability to target multiple metatargets at once is a small step away from being able to build the same target (cpp/obj/lib/alias) with different properties depending on how the dependent code needs to use it. But the latter is a huge leap from the one-target-one-command paradigm that so many are used to but that is so cumbersome for large C++ projects, especially ones that have interactions with other languages. Do you have a more concrete idea of how a multi-layer approach would simplify Jamfiles or build invocation? I don't see it getting rid of the basic sources/requirements/default-build/usage-requirements pattern. And whether I'm building multiple targets or not, I still love being able to use platform independent syntax: bjam path/to/foo//bar link=shared address-model=32 -Matt
At Tue, 29 Mar 2011 19:37:58 -0500, Matt Chambers wrote:
Do you have a more concrete idea of how a multi-layer approach would simplify Jamfiles or build invocation?
Yes. The single-build-invocation/multiple-target-variants approach means that almost everything in a Jamfile has to be done declaratively and everything must be parameterized to accept multiple build options, instead of accepting straightforward procedural code and dealing with a concrete set of build properties corresponding to the currently-selected configuration. As a result, BB contains higher-level abstractions than most people are used to dealing with in a build system.. These abstractions are not just unfamiliar, but they need to be documented, which has proven to be a challenge.
I don't see it getting rid of the basic sources/requirements/default-build/usage-requirements pattern.
Those abstractions are the ones I'd keep :-)
And whether I'm building multiple targets or not, I still love being able to use platform independent syntax: bjam path/to/foo//bar link=shared address-model=32
Me too. I'd keep that too, but it's worth asking whether these things we love are worth their cost to new Boosters, to our users, etc., and thus to Boost as a whole. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Tue, Mar 29, 2011 at 8:42 PM, Dave Abrahams <dave@boostpro.com> wrote:
[...] almost everything in a Jamfile has to be done declaratively and everything must be parameterized to accept multiple build options, instead of accepting straightforward procedural code and dealing with a concrete set of build properties corresponding to the currently-selected configuration. [...]
I've rarely heard the criticism of a build being too declarative! Having created large builds in the past (using Make and Ant) and now working with CMake, I feel that most builds in fact *lack* in their declarative nature, which makes them intractable when they grow large enough. CMake IMHO falls into that trap as well, relying too heavily on procedural code (with poor syntax too IMHO). Yes, build extensibility and flexibility do require a full featured scripting environment, but it's better exposed via a declarative facade. Too often the build is not even aware of the intended modularization of the software being built, and the dependencies of these modules/libraries/subsystems/etc... to document and enforce them for instance. (getting back to just lurking now)
On 30/3/2011 16:35, Dominique Devienne wrote:
On Tue, Mar 29, 2011 at 8:42 PM, Dave Abrahams<dave@boostpro.com> wrote:
[...] almost everything in a Jamfile has to be done declaratively and everything must be parameterized to accept multiple build options, instead of accepting straightforward procedural code and dealing with a concrete set of build properties corresponding to the currently-selected configuration. [...]
I've rarely heard the criticism of a build being too declarative!
Having created large builds in the past (using Make and Ant) and now working with CMake, I feel that most builds in fact *lack* in their declarative nature, which makes them intractable when they grow large enough. CMake IMHO falls into that trap as well, relying too heavily on procedural code (with poor syntax too IMHO). Yes, build extensibility and flexibility do require a full featured scripting environment, but it's better exposed via a declarative facade. Too often the build is not even aware of the intended modularization of the software being built, and the dependencies of these modules/libraries/subsystems/etc... to document and enforce them for instance. (getting back to just lurking now) _______________________________________________ Unsubscribe& other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Full Ack.
On 3/29/2011 7:04 PM, Dave Abrahams wrote:
The design made this tradeoff because it was primarily trying to serve developers and testers of Boost libraries on multiple toolsets. That turns out to not be the primary audience of our build system, since users end up having to deal with it---but even if that were the primary audience, I doubt that scaling the steep learning curve would be worth the benefit overall.
Even though I was the one who contributed to the increase of end users dealing with BBv2, with the creation of the build&install support, I've always been a proponent that having users rely on the Boost build setup is a bug. I.e. users should be able to drop source code into their own build system without *any* other extra effort. And the fact that many Boost libraries can't do that is sad. So Boost end users should *not* be the primary audience! And like Emil says in reply to this also, for those of us that use BBv2 the only painful drawback is the speed. Which is solvable in many ways. One of which, porting to Python, has shown the likely speed improvements. To put it another way.. Jam is an OK designed scripting base for BBv2.. But bjam is a terrible implementation of that design :-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
At Tue, 29 Mar 2011 19:38:47 -0500, Rene Rivera wrote:
Even though I was the one who contributed to the increase of end users dealing with BBv2, with the creation of the build&install support, I've always been a proponent that having users rely on the Boost build setup is a bug. I.e. users should be able to drop source code into their own build system without *any* other extra effort. And the fact that many Boost libraries can't do that is sad.
Very sad.
So Boost end users should *not* be the primary audience!
Well, but they are. What's your proposed way around it?
And like Emil says in reply to this also, for those of us that use BBv2 the only painful drawback is the speed.
As a member of that group, I beg to differ. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 1:59 PM, Dave Abrahams wrote:
At Tue, 29 Mar 2011 19:38:47 -0500, Rene Rivera wrote:
Even though I was the one who contributed to the increase of end users dealing with BBv2, with the creation of the build&install support, I've always been a proponent that having users rely on the Boost build setup is a bug. I.e. users should be able to drop source code into their own build system without *any* other extra effort. And the fact that many Boost libraries can't do that is sad. Very sad.
So Boost end users should *not* be the primary audience! Well, but they are. What's your proposed way around it?
Beat CMake. ;-)
And like Emil says in reply to this also, for those of us that use BBv2 the only painful drawback is the speed. As a member of that group, I beg to differ.
I'm open to the possibility that speed issues stem from the sheer size of the boost distribution.
Even though I was the one who contributed to the increase of end users dealing with BBv2, with the creation of the build&install support, I've always been a proponent that having users rely on the Boost build setup is a bug. I.e. users should be able to drop source code into their own build system without *any* other extra effort. And the fact that many Boost libraries can't do that is sad.
So Boost end users should *not* be the primary audience!
Actually I must admit it is wrong statement. Why? Because the libraries may be much more complicated then you think. Especially when it comes to handling DLL's where you need a special defines for DLL build. But this is only 5% of the problem. If you try for example build boost-system or other relatively simple libraries that do not have any external dependencies it is simple. Now when it comes to iostreams or regex it becomes more complicated (zlib, bzip2 and icu) Now lets take few other libraries that are now in review queue: - Boost.Context - it has platform/compiler conditional assembly sources and separate build options to use ucontext or fcontext. Do you really think it is possible to give a user sources and say compile them? - Boost.Locale - it depends on several libraries: ICU, iconv and boost-thread conditionally has 5 build options (with/out icu,iconv,win32api,posix-api, std-locale-api) and some of them should be turned conditionally for different platforms. So no I don't expect user to do all the job for me. This is why build system exists. Boost is lucky because its libraries and build are relatively simple. and before anybody screams about how sophisticated boost is I add - Almost no compile time configuration (something like generated config.h) - Almost no 3rd part dependencies. - Almost all configuration is done by ifdefs instead of configure like scripts that can test features automatically and not require from user to know every possible OS/Compiler setup. So that is why Boost.Build suites somehow Boost and in general this is why build system exist. A friend of mine that works with MSVC Projects only do not understand all buzz around makes/cmakes/autotools/bjams and so on because he writes software for one compiler and one platform... So MSVC projects suit him. But in real world Build system is essential part of any project.
And like Emil says in reply to this also, for those of us that use BBv2 the only painful drawback is the speed. Which is solvable in many ways. One of which, porting to Python, has shown the likely speed improvements. To put it another way.. Jam is an OK designed scripting base for BBv2.. But bjam is a terrible implementation of that design :-)
By no way bjam speed is the showstopper. If the only problem of BBv2 was its speed I was loving it. Artyom
On Wed, Mar 30, 2011 at 5:36 AM, Artyom <artyomtnk@yahoo.com> wrote:
[snip]
And like Emil says in reply to this also, for those of us that use BBv2 the only painful drawback is the speed. Which is solvable in many ways. One of which, porting to Python, has shown the likely speed improvements. To put it another way.. Jam is an OK designed scripting base for BBv2.. But bjam is a terrible implementation of that design :-)
By no way bjam speed is the showstopper. If the only problem of BBv2 was its speed I was loving it.
I do love BBv2. But in no way I think speed is its only problem. It is far from easy to extend boost.build to use different tools. And the documentation is specially lacking for this. But I'm confident the python rewrite will change this, specially since it might get more users which are very fond of python.
Artyom
Regards, -- Felipe Magno de Almeida
On 30/3/2011 10:36, Artyom wrote:
Even though I was the one who contributed to the increase of end users dealing with BBv2, with the creation of the build&install support, I've always been a proponent that having users rely on the Boost build setup is a bug. I.e. users should be able to drop source code into their own build system without *any* other extra effort. And the fact that many Boost libraries can't do that is sad.
So Boost end users should *not* be the primary audience!
Actually I must admit it is wrong statement. Why? Because the libraries may be much more complicated then you think.
Especially when it comes to handling DLL's where you need a special defines for DLL build.
But this is only 5% of the problem.
If you try for example build boost-system or other relatively simple libraries that do not have any external dependencies it is simple.
Now when it comes to iostreams or regex it becomes more complicated (zlib, bzip2 and icu)
Now lets take few other libraries that are now in review queue:
- Boost.Context - it has platform/compiler conditional assembly sources and separate build options to use ucontext or fcontext.
Do you really think it is possible to give a user sources and say compile them?
- Boost.Locale - it depends on several libraries: ICU, iconv and boost-thread conditionally has 5 build options (with/out icu,iconv,win32api,posix-api, std-locale-api) and some of them should be turned conditionally for different platforms.
So no I don't expect user to do all the job for me. This is why build system exists.
Boost is lucky because its libraries and build are relatively simple. and before anybody screams about how sophisticated boost is I add
- Almost no compile time configuration (something like generated config.h) - Almost no 3rd part dependencies. - Almost all configuration is done by ifdefs instead of configure like scripts that can test features automatically and not require from user to know every possible OS/Compiler setup.
So that is why Boost.Build suites somehow Boost and in general this is why build system exist.
Absolutely.
A friend of mine that works with MSVC Projects only do not understand all buzz around makes/cmakes/autotools/bjams and so on because he writes software for one compiler and one platform... So MSVC projects suit him.
Even then I would probably use CMake to automate finding of External libs (i.e. Boost), especially if one has several subprojects.
But in real world Build system is essential part of any project.
+1 Especially for Library development, where the user is always also developer. regeards Fabio
AMDG On 03/29/2011 05:04 PM, Dave Abrahams wrote:
Part of that is because the design tries to do too much. Specifically, the production of multiple build configurations with a single build command offers most users no benefit in exchange for the enormous complication it causes in design, implementation, and especially in writing build instructions (Jamfiles in our case).
Whatever you're talking about here, it's outside of my experience. I have never written a Jamfile that was made significantly more complex by the fact that multiple configurations can be built at once.
For the few who do benefit from the feature, the ability to build multiple configurations easily could have been written as another layer that invokes the build system multiple times.
I disagree. Being able to build multiple variants of libraries is pretty much a must-have on Windows, given that debug and release are not necessarily ABI compatible. I guess it doesn't matter much to me /how/ it's handled, but it can't be treated as an afterthought that doesn't really matter. In Christ, Steven Watanabe
At Tue, 29 Mar 2011 17:46:48 -0700, Steven Watanabe wrote:
AMDG
On 03/29/2011 05:04 PM, Dave Abrahams wrote:
Part of that is because the design tries to do too much. Specifically, the production of multiple build configurations with a single build command offers most users no benefit in exchange for the enormous complication it causes in design, implementation, and especially in writing build instructions (Jamfiles in our case).
Whatever you're talking about here, it's outside of my experience. I have never written a Jamfile that was made significantly more complex by the fact that multiple configurations can be built at once.
Then you either haven't done anything outside of the absolute basics (which I know is not the case), or you can't see the complexity for some reason.
For the few who do benefit from the feature, the ability to build multiple configurations easily could have been written as another layer that invokes the build system multiple times.
I disagree. Being able to build multiple variants of libraries is pretty much a must-have on Windows, given that debug and release are not necessarily ABI compatible.
Of course it is. But you don't have to do it in one invocationi of the basic build tool. You could configure builds from different root build directories. And then yous can automate that to make it seamless, if that's what you need.
I guess it doesn't matter much to me /how/ it's handled,
*Exactly*.
but it can't be treated as an afterthought that doesn't really matter.
I didn't say it doesn't matter. I said they way we dealt with the requirement made the solution more complex for everyone. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
AMDG On 03/29/2011 06:48 PM, Dave Abrahams wrote:
At Tue, 29 Mar 2011 17:46:48 -0700, Steven Watanabe wrote:
On 03/29/2011 05:04 PM, Dave Abrahams wrote:
Part of that is because the design tries to do too much. Specifically, the production of multiple build configurations with a single build command offers most users no benefit in exchange for the enormous complication it causes in design, implementation, and especially in writing build instructions (Jamfiles in our case).
Whatever you're talking about here, it's outside of my experience. I have never written a Jamfile that was made significantly more complex by the fact that multiple configurations can be built at once.
Then you either haven't done anything outside of the absolute basics (which I know is not the case),
The absolute basics have served me well. It's true that I've done more sophisticated things, but not in any way that's affected by this. I know (theoretically) that it can make non-trivial platform specific configuration harder, but that has never affected me, because I generally only write portable C++ with no dependencies outside Boost.
or you can't see the complexity for some reason.
I've written a lot of Jamfiles that look like: run test1.cpp ; run test2.cpp ; compile test3.cpp ; ... The biggest source of complexity in documentation Jamfiles is setting all the parameters for xsltproc and doxygen--no way out of that. The only compiled library I've written Jamfile for was for Boost.Random, which is about as basic as it gets. All the toolset specific configuration I've ever needed can be handled by conditional features like <toolset>msvc:<warnings>all, which is at least as clean as any alternative. I've done a fair amount of work with the documentation tools, but inside a generator, you are only dealing with one build variant at a time anyway. The same goes for the template profiler.
For the few who do benefit from the feature, the ability to build multiple configurations easily could have been written as another layer that invokes the build system multiple times.
I disagree. Being able to build multiple variants of libraries is pretty much a must-have on Windows, given that debug and release are not necessarily ABI compatible.
Of course it is. But you don't have to do it in one invocationi of the basic build tool. You could configure builds from different root build directories.
You can but it isn't quite as good as it doesn't make it easy to share things between configurations. Not that this ability is particularly important to me, but I have used it.
And then yous can automate that to make it seamless, if that's what you need.
Would it really be seamless? I'm inclined to doubt it.
I guess it doesn't matter much to me /how/ it's handled,
*Exactly*.
Well, obviously it *does* matter to *you*.
but it can't be treated as an afterthought that doesn't really matter.
I didn't say it doesn't matter. I said they way we dealt with the requirement made the solution more complex for everyone.
I think "everyone" is a huge exaggeration. The kind of tasks for which it matters should not be pervasive. If they are, then Boost.Build has failed much more fundamentally, or it's simply being misused. In Christ, Steven Watanabe
On 30/3/2011 5:51, Steven Watanabe wrote:
I think "everyone" is a huge exaggeration. The kind of tasks for which it matters should not be pervasive. If they are, then Boost.Build has failed much more fundamentally, or it's simply being misused.
I think this is exactly the point, it did fail much more fundamentally. From a perspective of a user of a library the build system of the library needs to double as the library installer. So the function of a build system which is probably used the most is: "make && make install" or "./configure && make && make install" if this commands (without any additional parameters!) doesn't find all external libs and the systems default toolchain, I consider that a very grave bug which could sway me to not depend on this library at all. Then I need some method to "link" against the lib (or include it for header only libs) which should not be much more onerous than something along the lines of FindPackage (Boost) again without any Path or similar parameters. For a developer (and in case of open source libs the developers were mostly users first) the next function I need is that it integrates nicely with my work environment. So a function like CMakes generators which generate Project files for common IDE's which also represent the structure of the lib, is a bit more than only a nice to have, because I would really resent having to do this manually. Next Features in order of importance: Test integration, (Binary) packageing (Multiple configs come into play here), interpackage dependency management. All just my very humble opinion regards Fabio
I guess it is the right time to give a little status update of my approach to a modularized build of the Boost C++ Libraries with CMake (see http://lists.boost.org/Archives/boost/2011/01/176154.php). The approach consists of two parts: 1. Boost.CMake is a collection of CMake modules to simplify the use and development of Boost libraries (at least for the subset of users and developers that like CMake). 2. Boost.Defrag is an aggregator that can collect the Boost libraries and tools from their individual repositories (cvs, svn, git, etc) and package them to a monolithic release. Example source packages and binary installers for Darwin and Windows are available at: https://github.com/purpleKarrot/Boost.CMake/downloads Packages for Ubuntu are built on Launchpad: https://launchpad.net/~purplekarrot/+archive/ppa/+buildjob/2378150 All these packages have been created with Boost.CMake and Boost.Defrag. WARNING: DO NOT USE THESE PACKAGES FOR PRODUCTIVE USE! But feel free to try the installers. Generated packages are completely modular, they contain over 200 (TWO HUNDRED!!) components. Dependencies are handled (dependencies may be incorrect, but the build system can handle them). Both debug and release libraries are included (multiple configs? no problem). When Boost is installed with an installer that was built with Boost.CMake, it gets installed as a "CMake Package" and can be found by the `find_package()` command in "config mode" (more about this mode: http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:find_package). Boost.CMake documentation (found in the same download section as the packages) is very preliminary but gives a little more introduction than this email. Any feedback is welcome, either here or in the issue tracker on github. cheers, Daniel
On Thu, Mar 31, 2011 at 12:48:53AM +0200, Daniel Pfeifer wrote:
The approach consists of two parts:
1. Boost.CMake is a collection of CMake modules to simplify the use and development of Boost libraries (at least for the subset of users and developers that like CMake).
2. Boost.Defrag is an aggregator that can collect the Boost libraries and tools from their individual repositories (cvs, svn, git, etc) and package them to a monolithic release.
Any feedback is welcome, either here or in the issue tracker on github.
The use of Boost.NameHere strikes me as odd, as I at first glance thought that the things mentioned were Boost libraries, as the Boost.NameHere naming scheme is typically used for those. In my eyes, prefixing something with "Boost." should be reserved for libraries, not arbitrary software somewhat related to the project. As for a more suitable naming scheme, I cannot come up with one, but I'm sure that the list can bikeshed something together. Previously the only offender (as far as I know) was Boost.Build. It'd be suboptimal to confuse things more. -- Lars Viklund | zao@acc.umu.se
On 03/30/2011 03:48 PM, Daniel Pfeifer wrote: [snip]
When Boost is installed with an installer that was built with Boost.CMake, it gets installed as a "CMake Package" and can be found by the `find_package()` command in "config mode" (more about this mode: http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:find_package).
Perhaps support can also be added for generating the seemingly much more standard (at least on Linux) pkgconfig format files, which can be used more easily with virtually any build system, rather than just CMake. (Possibly CMake could just use the pkgconfig files as well.)
Dave Abrahams wrote:
Part of that is because the design tries to do too much. Specifically, the production of multiple build configurations with a single build command offers most users no benefit in exchange for the enormous complication it causes in design, implementation, and especially in writing build instructions (Jamfiles in our case). For the few who do benefit from the feature, the ability to build multiple configurations easily could have been written as another layer that invokes the build system multiple times.
It would be true if all you ever wanted was to build *everything* using the same set of properties. However, if there's need to variate build properties of specific targets, outer wrapper just will not work. Say, program_option runs some tests using static link and some tests using shared link, which naturally builds the library itself twice with different configurations. Trying to do that with naive wrappers would mean you'd build *all* tests both using static linking and shared linking, at extreme expense of testing time. Of course, you can add some conditional to run some tests using static linking, no matter what, and very soon you'll reinvent all of Boost.Build again. In practice, while new users are often confused about declarative nature, maybe due insufficiently clear treatment of that in the docs, I can definitely tell you that it's not a big problem going forward. Conditional requirements, like <toolset>gcc:<cxxflags>whatever is something that seem to cause next to zero queries on Boost.Build mailing list and on IRC. - Volodya -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40
On 30/03/2011 02:04, Dave Abrahams wrote:
Part of that is because the design tries to do too much. Specifically, the production of multiple build configurations with a single build command offers most users no benefit in exchange for the enormous complication it causes in design, implementation, and especially in writing build instructions (Jamfiles in our case). For the few who do benefit from the feature, the ability to build multiple configurations easily could have been written as another layer that invokes the build system multiple times.
The design made this tradeoff because it was primarily trying to serve developers and testers of Boost libraries on multiple toolsets. That turns out to not be the primary audience of our build system, since users end up having to deal with it---but even if that were the primary audience, I doubt that scaling the steep learning curve would be worth the benefit overall.
Just so it's clear I'm not blaming anyone else: these problems are as much due to my own shortsightedness as to anything else.
Just a quick word to say that after I've done a lot of work with CMake, some non-trivial, I've come to fully agree with you. Setting up a single configuration in an outside directory with CMake and building it there makes things much simpler than the Boost.Build paradigm of building everything at once whenever you want to write simple code and let the user configure it to get what he wants. It's simply less overwhelming to only have to consider one process at a time. The separation between procedural code executed by cmake at configure time and the resolving of targets with dependencies by make at build time is also a great plus: that allows to have easy scripting within the CMakeLists.txt themselves. I'm actually quite looking forwarding to seeing the scripting capabilities of Boost.Build with the Python rewrite. What I'm still missing from CMake is the many high-level and high-portability features of Boost.Build. With CMake I often find myself writing my own modules to portably enable some flags etc.
On Wed, Mar 30, 2011 at 9:23 AM, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
Just a quick word to say that after I've done a lot of work with CMake, some non-trivial, I've come to fully agree with you.
Setting up a single configuration in an outside directory with CMake and building it there makes things much simpler than the Boost.Build paradigm of building everything at once whenever you want to write simple code and let the user configure it to get what he wants. It's simply less overwhelming to only have to consider one process at a time. The separation between procedural code executed by cmake at configure time and the resolving of targets with dependencies by make at build time is also a great plus: that allows to have easy scripting within the CMakeLists.txt themselves.
I'm actually quite looking forwarding to seeing the scripting capabilities of Boost.Build with the Python rewrite.
What I'm still missing from CMake is the many high-level and high-portability features of Boost.Build. With CMake I often find myself writing my own modules to portably enable some flags etc.
CMake is too flexible. You can do a lot inside CMakelists itself but due to that CMake itself can't be improved easily. IMO the simple case should be simple and 90% of the apps should be buildable with the simple case. -- Olaf
Perhaps you should be asking this on the Boost Build list (cc'd) <http://www.boost.org/community/groups.html#jamboost>. Where you are more likely to hear from people who use BBv2 outside of Boost. On 3/26/2011 10:08 AM, Gregory Crosswhite wrote:
Hey everyone,
Is there a reason why Boost uses Boost.Jam/Boost.Build for reasons other than tradition? Does it have advantages over other build systems, in particular CMake (which I consider to be its main competitor)? Are there many people/projects who use Boost.Jam/Boost.Build outside of Boost?
These questions are asked purely out of curiosity due to my ignorance of Boost.Jam/Boost.Build, not because I have an axe to grind.
Cheers, Greg
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
Gregory Crosswhite wrote:
Hey everyone,
Is there a reason why Boost uses Boost.Jam/Boost.Build for reasons other than tradition? Does it have advantages over other build systems, in particular CMake (which I consider to be its main competitor)? Are there many people/projects who use Boost.Jam/Boost.Build outside of Boost?
These questions are asked purely out of curiosity due to my ignorance of Boost.Jam/Boost.Build, not because I have an axe to grind.
First, this question is better asked on the Boost.Build mailing list. (boost-build@lists.boost.org). Second, some high-level description and comparison with exising build tools can be found at http://syrcose.ispras.ru/2009/files/04_paper.pdf In summary, whilst CMake was around for considerably more time and has some features that Boost.Build has not yet caught up with, is also comes with various historic baggage, and does not even remote approximation of most interesting Boost.Build features, in particular portable build properties and multivariant builds. I believe it will take Boost.Build less time to catch up on missing features that it would take to beat CMake the other way around (if that's even possible). Let's continue on boost-build mailing list, if you're interested. - Volodya -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40
Hi, On Sat, Mar 26, 2011 at 5:08 PM, Gregory Crosswhite <gcross@phys.washington.edu> wrote:
Hey everyone,
Is there a reason why Boost uses Boost.Jam/Boost.Build for reasons other than tradition? Does it have advantages over other build systems, in particular CMake (which I consider to be its main competitor)? Are there many people/projects who use Boost.Jam/Boost.Build outside of Boost?
I don't know if there are many projects, but my company uses boost.build as officicial build system. It was choosen due to its high portability and minimal dependencies. You only need to have C compiler and boost.build scripts installed and that is it. You don't need to depend on specific IDEs, autotools and even deep-seated make. Also, Jamfile declarative language looks pretty simple and expressive to me. For sure, it has issues: weak documentation, some tricky syntax ('space before ;' issue, I guess it's fixed now) etc. But from own experience, I can say that (after you overcome some obscure issues) it just works.
These questions are asked purely out of curiosity due to my ignorance of Boost.Jam/Boost.Build, not because I have an axe to grind.
Cheers, Greg
Regards
Message du 26/03/11 16:09 De : "Gregory Crosswhite" A : boost@lists.boost.org Copie à : Objet : [boost] Why Boost.Build?
Hey everyone,
Is there a reason why Boost uses Boost.Jam/Boost.Build for reasons other than tradition? Does it have advantages over other build systems, in particular CMake (which I consider to be its main competitor)? Are there many people/projects who use Boost.Jam/Boost.Build outside of Boost?
These questions are asked purely out of curiosity due to my ignorance of Boost.Jam/Boost.Build, not because I have an axe to grind.
Hi, I like Boost.Build, and I think it responds to the needs the developers of Boost have. CMake was included, I don't remember on which version, in a intrusive way without requesting even a review. Fortunately it has been removed from the official distribution. I agree that the Boost.Build documentation can be improved and that there are some features that could be added as any tool. The question is how Boost.Build could be now if all the effort to adapt CMake to Boost and write threads like this one had been used to improve the documentation and add the missing features? Just my 2cts Vicente
Vicente BOTET wrote:
Message du 26/03/11 16:09 De : "Gregory Crosswhite" A : boost@lists.boost.org Copie à : Objet : [boost] Why Boost.Build?
Hey everyone,
Is there a reason why Boost uses Boost.Jam/Boost.Build for reasons other than tradition? Does it have advantages over other build systems, in particular CMake (which I consider to be its main competitor)? Are there many people/projects who use Boost.Jam/Boost.Build outside of Boost?
These questions are asked purely out of curiosity due to my ignorance of Boost.Jam/Boost.Build, not because I have an axe to grind.
Hi,
I like Boost.Build, and I think it responds to the needs the developers of Boost have. CMake was included, I don't remember on which version, in a intrusive way without requesting even a review. Fortunately it has been removed from the official distribution.
I agree that the Boost.Build documentation can be improved and that there are some features that could be added as any tool. The question is how Boost.Build could be now if all the effort to adapt CMake to Boost and write threads like this one had been used to improve the documentation and add the missing features?
Thanks Vicente! I think your last sentence is very important one. We had many discussions about "infrastructure", that is things that are not C++ code in libraries. Often, it's suggested that we change, at the same time, the build system, the version control system, development workflow, review process and a couple of other things. And yes, it seems that the energy would better be spent on improving existing solutions. I've already mentioned it, but let me try a stronger wording. If all that energy went into Boost.Build, we'd have a build system written in Python, taking a split second for incremental build, integrated in a bunch of popular IDEs, and maybe even showing colorful output as thing build. Same goes for many other things -- version control, documentation in general, review process, test result reporting, release engineering. So, if you think something can be improved, ask yourself whether you personally, or your organization, and directly help. This is what can make a difference. Thanks, -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40
On 30.03.2011 21:16, Vladimir Prus wrote:
(...) maybe even showing colorful output as thing build
i use *acoc* util for it. (see colorified bjam output in attachments) [http://caliban.org/ruby/acoc.shtml] This tool isn't nice for me, ..but it works ;) -- - Do you speak English? Мужик с глубоким вздохом: - Yes I do. А хули толку?
On 30.03.2011 20:11, Vicente BOTET wrote:
I like Boost.Build, and I think it responds to the needs the > developers of Boost have. CMake was included, I don't remember on which version, in a intrusive way without requesting even a review. Fortunately it has been removed from the official distribution.
+1 -- - Do you speak English? Мужик с глубоким вздохом: - Yes I do. А хули толку?
participants (23)
-
Alexander Arhipenko -
Artyom -
Bjørn Roald -
Daniel Pfeifer -
Dave Abrahams -
Dominique Devienne -
Edward Diener -
Emil Dotchevski -
Fabio Fracassi -
Felipe Magno de Almeida -
Gregory Crosswhite -
Jeremy Maitin-Shepard -
Jim Bell -
Julian Gonggrijp -
Lars Viklund -
Mathias Gaunard -
Matt Chambers -
Max Sobolev -
Olaf van der Spek -
Rene Rivera -
Steven Watanabe -
Vicente BOTET -
Vladimir Prus