|
Boost-Build : |
From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-01-08 06:37:05
Toon Knapen wrote:
> 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 example:
[snip]
> > 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).
I guess this is partly technical and partly organizational problem.
In order to have boost.jam appear as a patch to the perforce jam, of even
better, as a number of patches from which interested persons can select
needed features, the best option would be to have boost.jam version in
Perforce public depot (in David's branch now) to
1. correspond exactly to the version in the Boost CVS
2. to have detailed change history, so that anybody who wants, say, modules,
will know the numbers of changes that he should integrate to get modules
support. (I think p4 has a feature to integrate a set of changes, given they
numbers?)
Of cause, it would take time to produce such a history for existing
enhancements. For future ones, this is very desirable. But this requires some
effort on developers part. Syncing Boost CVS & public depot will be extra
burden as well... unless Boost CVS is no longer used for Boost.Jam
development.
> 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.
Right!
- Volodya
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