Re: [boost] Why Boost.Build?

Subject: Re: [boost] Why Boost.Build?
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2011-03-27 05:01:25

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