Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-06-25 02:48:05

David Abrahams wrote:

> > 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.
> >
> > Thoughts?

> 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.

I'm still undecided on this one, but surely hacking in C would be more waste
of time than in C++.

> 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.

And here C++ might come handy. If say, I write "class Property_set", then
it will speed up current Boost.Build, but this class will be also usable in
the long run.

It's quite possible to use C++ class from Python, if we decide to use it.

> FWIW, also, I think it would be fairly trivial to build a Jam ->
> Python compiler :-).

I think that strategically, we better implement core features in a language
which is fast -- C++. I suspect that converting not very efficient code into
yet another language might have dramatic effect on performance.

Really, it probably would be much better if we implemented more stuff in C++
from the start, rather then trying to put everything into jam language layer.
After all, very few users, if any, will ever need to hack core modules like
properties.jam. For tools/* interpreted language is fine, but for core parts
it's probably not needed.

- Volodya


Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at