Re: [Boost-build] Improving Boost Build?

From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2007-05-18 11:05:17

Hi Michael!

On 5/17/07, Michael Caisse <boost_at_[hidden]> wrote:
> Dean Michael Berris wrote:
>
> <snip>
>
> > 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].
> >
> As you can probably tell from my previous posts... I'm keenly interested.

Yay! That makes at least two! :-)

> I've been pouring through bjam code and jam files for the past week trying
> to get a handle on the system. I'm not interested in a make generator. I
> have enough problems with nmake and the sort... I have much better luck with
> bjam (BBv2) so far. I think a user manual (I've been toying with an O'Reilly
> style guide/book) is required. Most people I know (except for those clever
> librarians) write "make" files by looking at examples of what they have
> done in the past. So a clear guide on what the grammar/language is followed
> with lots of examples might be a great start.
>

I agree about the book part. It would be something I think the people
at O'Reilly will be interested in if we actually get to writing a very
good book-style documentation.

A cookbook for Boost.Build and Boost.Jam would be very interesting. I
must admit, I'm not too much a fan of the "copy-paste" methodology,
but hey if it actually works then that's what's important anyway! ;-)

>
> <more snip>
>
> > 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.
> >
> >
> My first impression is that bjam has diverged enough from jam that this
> might make a lot of sense. Keeping similar code bases is helpful if there
> is some synergy that can be gained (shared bug fixes). I've been looking
> at the code and thinking about a C++ port that simply uses the standard
> library. This has initial appeal to me because it would not require the
> enormous boost package to build; however, I'm not sure it is worth loosing
> the boost library benefits.
>

Sounds like something that needs a plan and a committed effort to do.
I understand it might be a big undertaking, and I'm not opposed to
actually doing something about it. I just hope though that we set
reasonable expectations and goals as to what we actually want to
achieve in a given period of time.

Maybe separating the development of Boost.Build (forking off of 1.34.0
perhaps?) and having a different release/development cycle would
greatly help. Time based release anyone?

> <snip>
>
> > 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.
> >
> >
> It wont. There has been a good response from an existing user base. I don't
> mean to sound so negative about CMake, I'm sure it is a fine makefile generator....
> but I'm trying to get rid of the other make/nmake/vcproject/gmake systems from
> my builds.
>

Sounds very encouraging to me! :-)

>
> Best Regards -
>

Thanks Michael! I hope to be able to work with you on helping improve
Boost.Build! :-)

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