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