Re: [Boost-build] bjam 4.0.. in C++

Subject: Re: [Boost-build] bjam 4.0.. in C++
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2010-05-24 01:28:50

On Mon, May 24, 2010 at 2:06 PM, Robert Ramey <ramey_at_[hidden]> wrote:
>
> Trying to enhance performance is exactly the wrong place to invest your
> efforts right now.
>

Actually, I've been using Boost.Build and Bjam for a long time already
for non-Boost projects too. There is a learning curve but once you get
over that, it's not really a problem for me at least to figure things
out from the manual/documentation.

However, one of the biggest problems with Bjam is that it's slow and I
would agree that fixing this problem *now* is better than fixing it
later. If we can get Bjam to a point that rivals other build tools
like Scons in terms of performance, and maybe have it generate
"cached" instructions for building (for example, instead of going
through the whole analysis everytime you run bjam, have an option to
use a cached version of the tree and rebuild without doing the
analysis).

If bjam improves in the area of performance dramatically, then we can
start focusing on making the documentation meet the requirements of
everyday users too so that users can eventually become a community
that supports other (new/old) users who have problems with it. Right
now there are not a lot of users investing in learning the system
enough to be come experts like Volodya and Rene (and Steven) to be
able to help others -- we can address that in many different ways but
that's generally a people problem more than a technical problem.

> I'm going to sketch what I believe is the future of boost. Â Note that I'm
> not advocating this future - I just believe that this is what is going to
> happen.
>

Although I would encourage this discussion, I think it's worth
qualifying that this is a list on the build system. With that in mind
please see my comments on this issue below too.

> a) Libraries will become less coupled. Â Building and Testing libraries will
> be done "one at a time", "independently from each other".
>

I agree.

> b) Libraries will not necessarily all use the same build/test system.
>

I agree too.

> c) Developers will be able to choose which build system they will support
> and users will decide which of those supported they will use.
>

I agree as well.

> d) Bjam will have competition in the form of other alternatives. Â Right now
> bjam has a huge head start. Â We'll see what happens.
>

FWIW, Bjam is a great tool. However I don't see anything else that
does whatever Bjam does correctly.

CMake generates build files for Make, Visual Studio, and other build
systems. It's not entirely an apples-apples comparison there.

Scons does pretty much what Bjam does too but Scons is way more
horrible than any build system I've seen so far, so I'm not even
touching that.

> It seems you guys are really dedicated to keeping bjam the tool of choice
> and are willing to invest real effort to make that happen. Â That's a big
> commitment
> and I'm happy to see this. Â So I'm going to give you few suggestions which
> I think would help more people prefer to use bjam.
>
> a) Re-define your task
>
> Think of bjam as a general purpose make replacement
> rather than the "official boost build tool". Â I know you think you think
> that way
> but I don't see it. Â I expect to see a manual/tutorial with examples which
> walks
> one step by step through examples of increasing complexity. Â The manual is
> part of the program.
>

+1 -- I would really like to see bjam being treated as something
decoupled from Boost. If changing the name is one way of doing it,
then I would say we should be open to doing that too if not now then
in the near future. I like bjam and I think fixing the performance
issues would really give it a leg up on the other build systems and
tools out there.

I don't have a suggestion though on what to call it other than bjam --
maybe "better jam"?

> b) Re-define the concept of success.
>
> Currently the criteria for success is
> "It builds and tests all of boost".
> Change that criteria to:
> "Anyone smart enough to write a C++ program should be able to pick up
> the documentation, start at the beginning, read for 30 minutes, and be able
> to make a *.v2 file which will build his application for one or more
> platforms."
>

+1

> c) Re-define the concept of support.
>
> That criteria isn't met - e.g. he has to ask the list, then it's a bug in
> the documentation
> or user interface. Â Tweak the documenation and/or the user interface
> accordingly.
> Helping the user is important, but it's a "work around" which  "hides the
> bug" by letting
> solved. Â Well, the REAL problem is that the user had a problem. Â Treat this
> as a bug.
> If you do this, you'll find that little by little, the cost of support will
> diminish and
> you're users will be much happier.
>

This might be a community issue as well. Maybe a more human-oriented
effort would be required to build a community of users around bjam and
thus get more support for the continued development of the tool. Right
now it's only Boost doing so and maybe getting others to use Bjam
might be a good thing.

Has anybody ever thought of considering the integration of CMake and
bjam? Would that even be an option in your minds? (Having said that, I
should be asking the CMake guys though to leverage bjam and what's
already done there).

> If you buy this - granted it's a hard sell - you'll stay away from a large
> project to remake bjam in a faster version - which I believe would be a huge
> amount of work and
> wouldn't give you what you want and need - happier users and wider
> acceptance.
> You'll spend you time on making bjam easier to learn, harder to mis-use and
> more transparent when something goes wrong. Â This might seem like it's a lot
> of work - and it is - but it's much more likely make bjam more popular.
>

Well said Robert.

-- 
Dean Michael Berris
deanberris.com