From: David Abrahams (dave_at_[hidden])
Date: 2004-06-24 14:44:35
Vladimir Prus <ghost_at_[hidden]> writes:
> this morning I was thinking that some day (I hope soon), we'll have all the
> features ready and need to optimize Boost.Build V2. For example, I planned to
> implement certain parts of toolset.jam in C, and maybe
> property.jam/feature.jam too.
> But why restrict ourself to C? Boost.Build actually works on Windows and
> verious Unix flavours, all of which have some C++ compiler. Maybe one that
> can't grok explicit member specialization or "mutable", but which can handle
> classes and virtual methods just fine. I think that can bring us a lot of
> benefits when it comes to hacking in bjam core.
> And to add to my opinion, just now I've seen this:
> Even gcc developers consider requiring C++. If they consider it, than surely
> every other project can just switch. Also, one of the primary goals of
> Boost.Build is to be build system for C++ Boost -- which is collection of C++
> libraries. Surely user needs a C++ compiler anyway.
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.
FWIW, also, I think it would be fairly trivial to build a Jam ->
Python compiler :-).
-- 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