From: David Abrahams (dave_at_[hidden])
Date: 2004-11-24 10:24:28
Vladimir Prus <ghost_at_[hidden]> writes:
> I was publically promosing that even if
> Boost.Build uses SCons one day, we won't break any existing
> project. This means we need to support that syntax.
> OTOH, it is quite reasonable to use bjam for parsing Jam sources,
> and then invoke SCons build engine. In fact, this is the only
> reasonable approach given that I don't want to rewrite Boost.Build
> yet again:
> 1. Initially, bjam will invoke SCons at the lowest level (creating
> SCons Nodes instead of bjam's targets).
> 2. If that works out OK, we'd need to consider how to mix Python and
> jam language. Say, so that one could write new tool in Python.
> 3. After that, we can gradually move Boost.Build code to
> Python. Given that the languages are very similar, this should not
> be very hard.
I heartily support this approach! In fact, parsing and interpreting
Jam code using Python at some point shouldn't be too difficult either,
should we decide we'd like to do that.
I have to say that this would rekindle my enthusiasm for work on these
projects, provided we could also rededicate ourselves to complete and
understandable documentation at all levels of the project. That has
historically been a weakness of both Boost.Build and Scons, and
merging them without conscious attention to it could easily make the
> The biggest question is if it's reasonable to require Python for
> Boost.Build 2.0. I think that such idea will not find must
> opposition from Boost developers (there's a lot of use of Python
> already), but the question is if Boost.Build + SCons will be stable
> enough in time for 2.0.
The deadline for BB2.0 being... when?
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk