Boost.Build and SCons (Was: [scons-users] Debug ging information)

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-11-20 07:50:50

[jamboosters, this is cross-post of a message to SCons mailing list, which
discusses possible integration of the tools]

Stefan Seefeld wrote:

>> > Of course, that's Boost.Build point of view. I'm not yet sure if
>> > there's a
>> > better integration approach.
>> 
>> 
>> I'd love to hear some feedback from the people who are really
>> involved
>> with SCons (SK et al.).
>> SCons does an excellent job in building targets, BBv2 does an
>> excellent
>> job in specifying targets and their requirements and
>> usage-requirements
>> in a platform independent way.
>> I think the approach would be to build a layer on top of
>> SCons to allow
>> users to express higher level constructs than what is now
>> possible with
>> SCons. This would not require changing SCons in any way
>> whatsoever, but
>> I think the outcome will be better if more people are involved and
>> support the effort.
> 
> Agreed. As I said in another mail, I believe the strongest point
> of boost.build is the work that went into the taxonomy of tools and
> (high level) options. I'm not so sure about the syntax.
> As we are talking about python here I think there are a lot of options
> to define a DSL for declaring toolchains as well as writing
> high level sconscript files on top (i.e. an adaptation of Jamfiles).

It's not that simple. 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.

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.

- Volodya