Boost logo

Boost :

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-02-25 17:43:30


----- 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
users. It seems like an enormous waste of everyone's time to push for others
to adopt an approach that won't solve your problems.

-Dave


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk