Re: Improving Boost Build?

On 5/16/07, David Abrahams <daveboost-consulting.com>
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
+63 928 7291459
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

Re: Improving Boost Build?

Thread: Re: Improving Boost Build?