Boost logo

Boost :

From: Braden McDaniel (braden_at_[hidden])
Date: 2002-02-26 00:01:02


On Mon, 2002-02-25 at 20:07, David Abrahams wrote:
>
> ----- Original Message -----
> From: "Braden McDaniel" <braden_at_[hidden]>
>
> > > 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.
> >
> > I don't follow you. How do you think "make install" impinges upon Boost
> > developers' freedom to break source and binary compatibility in their
> > libraries?
>
> It doesn't, in any way. However, at least as I understand it, you want to
> tell users to get the boost distribution separately and configure/install it
> so you don't have to include it in your own distribution.

Right.

> Since we're
> constantly breaking binary compatibility and sometimes breaking source
> compatibility it seems to me that there's the very real possibility that the
> boost installation users get will be incompatible with whatever you're
> shipping. Avoiding that problem without including boost in your own
> distribution would impinge on boost developers' freedom.

There is no problem. Open source projects deal with dependencies in this
state *all the time*. In some cases where compatibility has been broken,
my project would simply fail to compile. That is appropriate. A quick
trip to my project's docs would tell the user, "This software is known
to work with Boost version X.Y."

In other (somewhat more insidious) cases, compilation may succeed,
though there is still some compatibility problem that would surface at
runtime. These cases are exactly what autoconf is for: my project would
simply include an autoconf test to ensure the installed Boost version is
not problematic.

(And note that autoconf can be used to trap the former case as well, in
case a compiler error isn't deemed user-friendly enough.)

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