Re: [jamboost] Boost.Build and SCons

From: Steven Knight (knight_at_[hidden])
Date: 2004-12-13 13:12:32

Hello Pedro--

I'm very glad you're interested in this sort of integration and would
be glad to help out to whatever extent I can. Your vision of providing
another interface is precisely one of things we've tried to allow for in
maintaining a separation between the Python-script interface layer (the
SCons/Script/*.py modules) and underlying build engine (everything else).

I'm sure we didn't do a perfect job at keeping clean separation everywhere
between the build engine and the SCons interface layer, but wherever
you find a place where it isn't, I'll be very glad to work with you
(and anyone else who participates) on refactoring things to make sure
the engine can support multiple interfaces.

One follow-on comment:

> I recently told Volodya I was going to spend some time experimenting 
> the integration between Boost.Build and SCons.
.
.
.
> The integration with SCons can be done:
> - at the SCons.Environment level, calling builder methods to create BB 
> virtual targets
> - at the lower level Node ADT interface
> 
> I really don't like SCons Enviroments because they are too cluttered 
> with functions, are too unwieldy, load all tools by default, etc.
> So I prefer the second approach: it provides all the functionality bjam 
> provides (and more) and fits very well with BB's architecture.

The issue I see is that Environments are pretty integral to the SCons
ability to build Nodes. My guess is that you'll need something that
at least resembles an Environment closely enough to interact with key
engine subsystems.

That said, I agree with you that SCons Environments have become too
heavyweight. To that extent, we will be cleaning up how Environments
handle Tools at some point in the (relatively near) future, after 0.97
is out.

I'd be very interested if your project (or anyone else) came up with
some sort of "minimal Environment," for example, that still made things
build correctly. What I'd be inclined to do is fold that into the SCons
build engine itself, so there's a relatively lightweight Environment base
class appropriate for all interfaces, and the "cluttered" Environment
subclass(es) can be ignored by interfaces like yours that don't need
the extra stuff.

Let me know if you have any questions or there are things I can do
to help.

--SK