[boost] Actually helping Boost (Was: Why Boost.Build?)

Subject: [boost] Actually helping Boost (Was: Why Boost.Build?)
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2011-03-30 13:16:07

Vicente BOTET wrote:

>> Message du 26/03/11 16:09
>> De : "Gregory Crosswhite"
>> A : boost_at_[hidden]
>> 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
[phone]