Re: [Boost-build] Improving Boost Build?

From: David Abrahams (dave_at_[hidden])
Date: 2007-05-17 11:15:59

on Thu May 17 2007, "Dean Michael Berris" <mikhailberis-AT-gmail.com> wrote:

> On 5/16/07, David Abrahams <dave_at_[hidden]> wrote:
>>
>> on Wed May 16 2007, "Dean Michael Berris" <mikhailberis-AT-gmail.com> wrote:
>> >
>> > First answer I have to this question, is documentation. Let's please
>> > either settle differences the manly way and call a spade a spade: we
>> > have poor documentation, and thus let's fix it.
>>
>> When you say "let's," who are you talking about?  I'm not going to fix
>> it.  I don't understand the system well enough to do so.  Who does?
>>
>
> When I said "let's", I meant people either already involved in the
> effort of documenting it and people who actually want to get involved.
> I obviously am one of the "let's" I refer to, and I was hoping you
> were part of it as well.
>
> Now that the intention is clear that you don't want any part of the
> "let's fix it [documentation]" effort, I guess that leaves just
> Vladimir Prus and I -- and maybe other people who haven't sounded off
> yet [so PLEASE LET US KNOW NOW WHO YOU ARE].

Let me be clear about this: it's not exactly that I don't want any
part of it, but that I can't afford to take part, especially if there
is a viable alternative for Boost.  I have too many other
responsibilities.  It was at one time my intention to work on the
**user-level** documentation, to increase usability for end-users
because having a workable build system for Boost is crucial to its
future.  In the end, all I could really do was our new getting started
guide, and even that was a major effort.

Note that all the work we could do to make things easier for users
would do very little (not nothing, but little) to make it easier for
new programmers to work on the system.  The documentation of the
system's architecture and its implementation is a whole other bag of
worms.

>> > Yes, the pioneers have been burned out trying to make Boost.Build the
>> > build system that it is today -- and I guess not getting enough
>> > positive feedback contributes to the frustration.
>>
>> No, the frustration for me comes from having a codebase I could not
>> understand from the first day I returned my attention to the project
>> after kicking it off...  and things have not improved in that respect,
>> from my point-of-view.
>
> Okay... Point taken.
>
> So I guess we can *try* to make up for that (and when I say "we", I
> meant everybody who wants to improve the situation whether that
> includes you or not) by actually doing the harder things that need
> doing. Like documentation, cleanup, simplification, improvement, and
> building a community around it (whether that be possible or not).
>
> It might be taking on burden people haven't wanted to take on for
> the longest time, but somebody's gotta do it. And since I'm bent on
> converting myself from a "user" to a "contributor" -- and since I
> can spare the years still being in my early twenties -- I'd like to
> try and do it.

More power to you.

>> > I guess shooting for the stars is not a bad idea, but I guess the
>> > point of the discussion is now diverging on the actual use of CMake
>> > in the Boost C++ Library and the improvement of Boost.Build. Trying
>> > to make Boost.Build what CMake is might not be for the best interest
>> > of Boost.Build users -- rather we should put in features that
>> > Boost.Build users (such as myself, and others on the list) would
>> > like to have in Boost.Build, and get more people involved in the
>> > effort.
>>
>> How would you like to have a system that begins building
>> instantaneously when you ask it to build?
>
> When you say instantaneously, do you mean you don't want to see the
> "... patience ..." thing 

Yes, or even the long wait before "... patience ..."  In BBv2
"patience" shows up only during dependency analysis.  Most of the time
before that goes into interpreting the code in your Jamfiles, etc.

> or be "fool proof with fancy AI" that you don't need to tell the
> build system how your project is organized and which binaries are to
> be built, linked, or whatnot?

Not that.

> The "bjam being slow and resource hungry" problem might be addressable
> somehow -- how I don't know yet, but I'm guessing it might require
> doing major surgery on the jam codebase (which is in C). It might also
> involve having to use Boost.Graph for the dependency tracking,
> Boost.Spirit for parsing the Jamfiles, Boost.Filesystem to work on the
> files, and maybe Boost.Python to expose these lower level
> services/components to a Python engine which drives the build process
> (using the external tools like compilers, linkers, assemblers,
> whatnot). I don't know if the above makes sense or whether it's
> feasible but leaving the jam legacy code might be a step in the right
> direction.

Wow.  Big project.

>> > So as far as the question of using CMake or not using CMake in the
>> > Boost C++ Library is concerned, I'd leave that up to the Boost
>> > developer community at large. However for the current discussion of
>> > improving Boost.Build, I don't particularly see the need to turn
>> > Boost.Build into a CMake look/work-alike if we intend to keep
>> > Boost.Build a distinct and usable (better?) build system that it is.
>>
>> Here's my point: *especially* if Boost isn't going to be using BBv2 as
>> its main build system, I simply can't afford to spend any more energy
>> trying to improve it.  I don't think BBv2 is better than CMake by any
>> truly objective criterion (although I may have an aesthetic preference
>> for some BBv2 design choices), and I think CMake has some real
>> advantages over BBv2.  My research even indicates that it's easy to
>> add usage-requirements to CMake.  Even though BBv2 is -- to a
>> significant degree -- my vision, I'm not afraid to admit that someone
>> else has done a better job.
>
> When I meant "better", I was referring to it being better than *other*
> build systems like Autotools+Make, Scons, Ant.
>
> As far as advantages of CMake is concerned, then I would agree that
> there are compelling reasons to make CMake the default build system
> for Boost.
>
> And for the part about it being your vision, I am grateful that
> someone like you has enough vision and guts to actually even try
> coming up with a build system that other people could actually use and
> be productive in. And I admire the humility of conceding that other
> people have done a better job.
>
> Now I think letting others pick up where you and others have left off
> (after the years you've spent on building Boost.Build) would be
> enough. So thank you Dave for all the hard work, some people (like me)
> would like to help you out by actually trying to take over whatever
> else needs to get done with Boost.Build.
>
> So if Boost does decide to use CMake as *the* build system of choice,
> I still don't see why Boost.Build would have to disappear into the
> sunset when people actually use it.

Absolutely; as long as it has a user base, it has life.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
Don't Miss BoostCon 2007! ==> http://www.boostcon.com