From: Pedro Ferreira (pedro.ferreira_at_[hidden])
Date: 2004-11-22 09:00:03
Em 20 Nov 2004, às 12:30, Vladimir Prus escreveu:
>>> but I'm definitely interested in some SCons integration. To begin
>>> with, if
>>> someone could embed Python in bjam and use SCons's build engine to
>>> execute commands (except for bjam's build engine), that would be very
>>> welcome thing.
>> Give me just a couple of days and I'll get back to you on this.
> Cool! If you do it this feature will get notable place in Boost.Build
I said I'd get back to you, not that I was going to do it in a couple
of days :-)
[ Below is the reply to another post]
> 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
>>> with SCons (SK et al.).
>>> SCons does an excellent job in building targets, BBv2 does an
>>> job in specifying targets and their requirements and
>>> 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
> uses SCons one day, we won't break any existing project. This means we
> to support that syntax.
> OTOH, it is quite reasonable to use bjam for parsing Jam sources, and
> invoke SCons build engine. In fact, this is the only reasonable
> given that I don't want to rewrite Boost.Build yet again:
> 1. Initially, bjam will invoke SCons at the lowest level (creating
> Nodes instead of bjam's targets).
> 2. If that works out OK, we'd need to consider how to mix Python and
> language. Say, so that one could write new tool in Python.
> 3. After that, we can gradually move Boost.Build code to Python. Given
> the languages are very similar, this should not be very hard.
I agree that this is, in fact, the best approach, despite the fact that
I share Stefan's opinion regarding the language.
Still, if we eventually reach the point where we have an API to define
targets and all, developing parsers for the language of one's choice
wouldn't be too hard.
I can give it a try and integrate bjam and SCons, although I will need
your guidance in the lowest level details of bjam. Again, let me finish
a few things I have to do and then I'll contact you.
Stefan (or anyone else!): are you interested in helping out?
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