From: Braden McDaniel (braden_at_[hidden])
Date: 2002-02-25 19:47:49
On Mon, 2002-02-25 at 17:43, David Abrahams wrote:
> ----- Original Message -----
> From: "braden_mcdaniel" <braden_at_[hidden]>
> > --- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> > > Are you planning to ask users to CVS a particular version of boost onto
> > > their system? That's what would be required currently. We try to
> > minimize
> > > this of course, but binary and source compatibility break on a regular
> > > basis.
> > No... There is absolutely no way I'd impose that on my users. Once
> > possible approach now is to:
> > * import a Boost release into my CVS tree as a 3rd-party source.
> > * incorporate it into my build system.
> > * include Boost with my distribution.
> > 3rd-party sources are really annoying to deal with. Even more annoying
> > is the bloat my distribution would take on as it incorporated boost.
> > There is also the approach Spirit has taken. Rather than include all
> > of Boost, they've picked out the parts they depend on. This saves
> > their distribution from being bloated, but updating to new versions of
> > the Boost sources becomes more complicated (especially if the
> > dependency graphs within Boost ever change).
> > Both of these approaches impose more work than using Boost should
> > impose. That's subjective, of course. But as far as I'm concerned, it
> > means that the amount of work involved is sufficient that it would
> > probably keep me from using Boost. Hence my involvement in this
> > discussion.
> Okay, but (I realize I may have missed something, but) AFAICT the
> configure/install approach proposed so far wouldn't address this issue.
> Since we *do* break source compatibility from time-to-time (and binary
> compatibility often) and we explicitly *don't* want to prevent developers
> from improving the design of their libraries in ways that break this
> compatibility, I don't see that a configure/install system would help your
I don't follow you. How do you think "make install" impinges upon Boost
developers' freedom to break source and binary compatibility in their
> It seems like an enormous waste of everyone's time to push for others
> to adopt an approach that won't solve your problems.
Right. We're spending all this energy on something that would be of no
help. A little credit, please?
-- Braden McDaniel e-mail: <braden_at_[hidden]> <http://endoframe.com> Jabber: <braden_at_[hidden]>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk