|
Boost-Build : |
From: David Abrahams (dave_at_[hidden])
Date: 2004-06-26 09:19:37
Toon Knapen <toon.knapen_at_[hidden]> writes:
> David Abrahams wrote:
>
>
>> Aside from other concerns voiced here, I am not sure how extensive you
>> want to make these changes, but I think any major expenditure of
>> effort on the low-level build tool is a waste of time in the long run.
>> Fundamentally, the original product from Perforce is not very good
>> software, and it's unreasonably difficult to create good software in
>> the Jam language. We've corrected a lot of that, but I think we're
>> near the end of that road. I really think in the long run we ought to
>> be thinking in terms of preserving the architecture of Boost.Build,
>> but of dumping the Jam heritage.
>
> IIRC a few months ago you mentioned that bjam could be reimplemented on
> top of scons. Is this indeed your vision on the evolution of bjam?
It seems like a possibility worth considering, because those Scons
guys have dealt with all of the low-level build system issues like
dependency analysis and parallelizing builds, and the Python guys have
dealt with all the low-level interpretive language issues like how to
implement classes, strings, etc. and all of the system-level issues
like how to implement a portable popen.
>> FWIW, also, I think it would be fairly trivial to build a Jam ->
>> Python compiler :-).
>
> And thus this could mean that jam rules could be translated to scons
> scripts?
Well, probably not "scons scripts" in the sense of what scons users
are used to seeing; more likely just Python functions. There's an
"upper layer" of what Scons does that we're probably not interested
in using, and I'm guessing that scons scripts speak to that layer.
-- 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