From: David Abrahams (dave_at_[hidden])
Date: 2004-12-13 13:49:53
Pedro Ferreira wrote:
> Dear all,
> I recently told Volodya I was going to spend some time experimenting
> the integration between Boost.Build and SCons.
> Unfortunately, I have been flooded with urgent tasks so I still haven't
> managed to spend more than an hour or so doing this.
> I see interest from many of us in pursuing such an integration so I
> think we need to debate where are we going to and which path should we
> My vision is:
> - create a 100% Python Boost.Build library on top of SCons
> - create a parser for the bjam language
That's a good goal, but I think the steps outlined by Volodya in
the right way to get there.
> This would allow people to use Jamfiles but would provide a Python
> interface to Boost.Build, which would open way to a myriad of tools,
> such as graphical browsers/creators, builder GUIs, etc.
> 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.
I had the same feeling about Environments.
> Regarding the approach, I see two possibilities:
> - do a progressive transition from bjam to Scons, keeping it working at
> all times
> - port everything from the ground up to Python until eventually it is
> Just out of curiosity, I tried to port generators.jam to Python. It's
> 40k worth of bjam code and I did it in afternoon, including some unit
> tests and adapting the comments do Python doc strings.
Note that the algorithm used by generators.jam for calculating
intermediate targets and build steps is not really general at all, but
tuned for a specific case (Qt-related, I think -- .whl, .dlp, and .wd
files are involved).
Related messages are in the threads at: http://tinyurl.com/68xc4,
As a result I created a prototype of how the generator search *ought* to
proceed... and it's written in Python! It lives in
Unfortunately it's not trivial, but I think it represents the "right"
logic from a conceptual standpoint. It has some significant comments,
but could definitely use more.
> So, my feeling is that it would be more efficient to go the latter way.
> I'm willing to invest a reasonable amount of time in this effort,
> should others be interested in collaborating too.
> Comments are welcome.
I'm interested also, provided that we agree to more fully document the
code as we convert it. I think it would be fun to do and it would help
us to get a grip on the codebase.
-- 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