Re: [Boost-build] Improving Boost Build?

From: Michael Caisse (boost_at_[hidden])
Date: 2007-05-17 14:52:00

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

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

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

Best Regards -

-- 
----------------------------------
Michael Caisse
Object Modeling Designs
www.objectmodelingdesigns.com