From: Toon Knapen (toon.knapen_at_[hidden])
Date: 2002-01-07 03:31:52
David Abrahams wrote:
> There's been a lot of action on the jamming mailing list recently, as you
> can see at http://maillist.perforce.com/pipermail/jamming/. Matt Armstrong
> and Craig McPheeters have been especially active in contributing useful
> fixes and enhancements, many of which we can use, and the Perforce people
> are beginning the project of rolling the outside enhancements back into the
> official source. They have not contacted me about getting our enhancements,
> which probably means that they are not going to take them in this round. In
> part, I guess this is because the Boost.Jam source has moved too far away
> from the Perforce code for their taste. On the other hand, there are a
> number of changes which would make a lot of sense for them to adopt. For
> Win95 support
> Elmination of fixed-sized buffers and associated overruns
> Reference-counting bug fixes
> Error reporting backtraces
> Reporting of source line numbers in -d+5 dumps
> Argument lists and rule argument checking
> ...probably others...
> We should discuss what response we should have to this situation, if any. If
> Perforce Jam is going to be actively developed, there would be significant
> advantages to staying close to it.
I think it would be a good idea to keep boost.jam as some kind of patch
in respect to the 'official jam' (certainly since it started evolving
again) and since there a lot of other good patches (Matt Armstrong,
...). Of course, this way, boost.jam will probably evolve slower as we
would like but it will be better in the long run (btw we're a too small
community ourselves to maintain boost.jam ourselves : you are already
spending some much time on it).
If we would not keep boost.jam a patch to Jam, I think it's better to
take the more drastic decision to e.g. use Python (as Matt Armstrong
suggests is the msg : possibility of merged codebase.
So I think it's a good idea to suggest all the improvements maid by
boost.jam to the root jam, but item per item, starting with the items
that are easiest to integrate in the root. Boost.jam has so much evolved
that I guess the other people choke when they see the whole bunch of
changes at once.
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