Re: [Boost-build] Future development

From: Douglas Gregor (doug.gregor_at_[hidden])
Date: 2007-10-03 22:42:49

On Oct 3, 2007, at 8:15 AM, Vladimir Prus wrote:
>> I think the answer is "bjam". As you said above, the Jam language is
>> essentially undocumented. It's also a rather odd language, and its
>> eccentricities are exaggerated by the object-oriented system BBv2 has
>> built on top of Jam. We picked Jam several years ago, when Perforce
>> was still working on it and it looked like there would be an active
>> community around Jam. That hasn't happened, and we're somewhat
>> isolated in our use of this language and build tool, forced to
>> customize and maintain "bjam" on our own.
>
> 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.

>> So, while we're pondering a re-write of the implementation language
>> of Boost.Build, let's consider carefully whether Boost.Build would
>> benefit from taking its ideas into a wider community. We have some
>> support in the CMake community already, and we have a promising
>> sketch of what Boost.Build could look like built on top of CMake. If
>> we truly believe in the ideas of Boost.Build, and those ideas are as
>> good as we think they are, we can leverage the CMake community to
>> spread those ideas further and realize those ideas on a grander scale
>> than we can possibly do from our community alone.
>
> 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.

> 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?

> 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.

> given that Cmake is using yet another
> home-grown language nobody knows

You know, it's funny. Back in 2002, I learned CMake and used it in a  
research project. It was around the same time I dug into Jam and  
BBv2, to implement the BoostBook toolchain there. I've been using  
BBv2 in all of the years since then, but hadn't actually touched  
CMake again until earlier this year (in May). What shocked me is that  
I was still able to write CMake code perfectly well 5 years later  
(with its reference documentation in a browser window, of course),  
and yet every time I try to tweak something in BBv2, whether it be  
BoostBook, MPI support, or Python, I end up struggling with this system.

I'm just looking in the "Modules" directory of CMake 2.4, and the  
number of user-contributed modules for finding various libraries and  
tools (from Doxygen to Expat to Latex to ZLIB) is pretty significant.  
I just don't buy your assertion that "nobody knows" the CMake language.

> 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),

You seem to be saying that CMake is not a build system "in use". I  
wonder what that means, given that, for example, the KDE project is  
using CMake:

        http://lwn.net/Articles/188693/

> 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.

> 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?

        - Doug