Re: [Boost-build] Future development

From: Vladimir Prus (ghost_at_[hidden])
Date: 2007-10-04 02:08:47

Douglas Gregor wrote:

[original email rearranged 

>> You surely understand that with core in Python, the amount of
>> maintenance and customization necessary for bjam will be greatly
>> reduced,
>> almost to the point of being zero.
> 
> Reimplementing in another language doesn't necessarily fix anything.

It surely "fixes" the need to implement classes, modules, and a zillion
of builtins in bjam.

>> First, Boost.Build is a little bit more than "debug" and "release"
>> build
>> variants. It's the whole set of features, the way features are
>> propagated,
>> the way projects are arranged, and they way targets are built. It
>> seems
>> unlikely to take all those things and implant them into any other
>> existing
>> build system.
> 
> Our CMake-based build system for Boost is a lot more than "debug" and
> "release", which is pretty obvious to one who has read the
> documentation for it. Did you even look at the CMake-based build
> system documentation I linked to?

Yes, did you look at Boost.Build docs? Does you system supports all Boost.Build
features? Does your system support all features the current Boost.Build-base
build of Boost has? 

>> Second, implementing all of Boost.Build using Cmake is likely to be
>> as hard
>> as Python port, and actually,
> 
> For reference, Troy and I hacked together what we have now for the
> CMake-based system in our spare time over 2-3 weeks.

See questions above.

>> is likely to move us from another
>> dead-end to another. Really, I'm not looking into writing anything
>> in cmake
>> language ;-)
> 
> Is that based on your experiences using CMake, or something else?
> 
>> So, to summarize your "let's consider carefully" sounds good, but
>> it won't
>> work. We can collect the list of all build system in use (Cmake is
>> not one),

The above should have read "Cmake is not the only one".
 
>> consider relative merits of using them as opposed to Python port, but
>> the only way to know for sure is to go ahead with coding.
> 
> I just don't buy the argument that porting to Python will magically
> fix what ails us with BBv2 and bjam.

It's my impression that bjam as internal logic language is one of the
most important problems. You might feel differently, I see no
practical way to convince each other.

>> Judging from the current distribution of user complains, it seems
>> to me
>> that Python port is going to be immediate improvement, and the end
>> result will be pretty good. Other approaches seem much more risky.
> 
> "Pretty good" seems like a weak end-goal for a complete rewrite of
> Boost.Build in a different language, no?

Only if you view complete rewrite as a big project ;-) And "pretty good"
actually means "Boost.Build as it is now, without biggest problem".

>> I don't quite agree with this logic. Say there's project A and
>> project B,
>> in same domain. Project A has objectively more users, and was
>> around for
>> longer. Does it mean project B should always be implemented within
>> project
>> B? I don't think so.
> 
> This is a Straw Man argument, and it doesn't help. The fact is that
> by building on CMake, we get all of the features of CMake now, plus
> everything that the CMake community adds in the future (including
> maintenance), all for free. If we build everything ourselves, we
> maintain everything ourselves.

This statement applies to any other competing project that has one 
developer more than Boost.Build. Why not use SCons, for example?

So, let me, just like Rene just did, summarize my position. Boost.Build
is a standalone project, with several ideas in it and it's developed
because those ideas seems worthwhile folks working on it. C++ Boost,
while getting "priority support", is not the end goal of Boost.Build.

Boost.Build has some problems, and some of the problems can be solved 
by using pre-existing solutions. However, judging those solutions
from "can build C++ Boost and has larger community" standpoint is not 
sufficient. Another important factor is how that other solutions are
compatible with Boost.Build design and ideas. And on that grounds,
I'm not looking into using cmake. OTOH, Python looks like good
and immediately useful pre-existing solution.

- Volodya