|
Boost-Build : |
From: David Abrahams (gclbb-jamboost_at_[hidden])
Date: 2003-06-18 07:00:15
Vladimir Prus <ghost_at_[hidden]> writes:
> David Abrahams wrote:
>> Vladimir Prus <ghost_at_[hidden]> writes:
>> >> (BTW, are you guys aware that Ralf W. Grosse-Kunstleve is already using
>> >> or shipping Boost, I believe, with an SCons-based build system for
>> >> cctbx, his Computational Crystallography ToolBox? I guess he has about
>> >> twenty lines of Python code that parse up the .jam or .bjam or whatever
>> >> files and turn them into calls into the SCons build engine. Might be a
>> >> useful starting point to look at how someone else has done some of the
>> >> basic stuff.)
>> >
>> > Need to look. Since Python version of Boost.Build is only distant
>> > plan for now, we'd have a lot of Jam code by the time it
>> > works. Another alternative I was thinking about was extending Python
>> > with Jam. So, you'd have Python function "compile_jam_file", or
>> > something.
>>
>> That sounds like we'd be giving up many/most of the advantages of
>> Python. Consider Jam's poor data abstraction capability. We
>> wouldn't even be able to touch regular Python classes.
>
> I'm not sure what you mean. My intention was that Jamfiles could
> remain as is, but the rest of the system could be rewritten in
> Python. So Jamfiles will really be calling Python rules from
> Boost.Build --- like "exe" or "lib".
>
> Jamfiles won't be able to use anything sophisticated --- like
> declaring new generators, or main target types. Such code would have
> to be rewritten. But supposedly, it's only small fraction of code,
> compared with Jamfiles.
I'm sorry; when you said "we'd have a lot of Jam code by the time it
works" I assumed you meant code in the build system, not in users'
Jamfiles. If you're just suggesting to keep the Jam interpreter for
handling Jamfiles, I guess I'd say that it's probably easier to write
a Jam syntax interpreter or translator in Python than to extend Python
with the Jam interpreter, though the latter is certainly fairly easily
doable.
I'd rather not remain tied strictly to the Jam syntax forever, and at
that point it would be much better to have Python code interpreting
something like it.
-- Dave Abrahams Boost Consulting 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