Re: [Boost-build] Improving Boost Build?

From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2007-05-17 07:33:06

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

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

> > So the third answer to this question is that rather than relying on
> > the pioneers to do all the work, I'd much rather be mentored by the
> > pioneers (if time and materials allow it) in terms of answering "how
> > to do this?" questions than actually burdening the original
> > developers with the task of actually making the changes.
>
> I think only one pioneer can really help you.  I only know the core
> bjam language and a few details around the edges of the higher-level
> BBv2 system.  For everything else, I have to dig deeply into the code
> myself and often I don't find the answers I seek.
>

Fair enough then I guess, I'll try working closely with the only
pioneer who can help me (who I'm inclined to believe is Vladimir Prus)
then to start making things happen.

I understand BoostCon is still under way and that other people
attending might want to take over the volunteering to fix the
documentation project, so I'll wait until things normalize again
before writing up plans and action items. At any rate, I'll start
bringing on the pain by actually reading the .jam files that make the
whole BBv2 system tick (or do magic FWIW).

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

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.

The other part about having the build system be artificially
intelligent and figure out what you want without even telling it what
to do might be a good research problem I'm not sure I want to even get
near *that* effort. But if someone could make it happen, then I guess
yes I'd like a build system which "begins instantaneously when you ask
it to build" regardless of you telling the system what to build.

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

-- 
Dean Michael C. Berris
http://cplusplus-soup.blogspot.com/
mikhailberis AT gmail DOT com
[phone]