Re: Installing Boost (WAS: Re: [boost] Re: Why Jam?)

From: Braden McDaniel (braden_at_[hidden])
Date: 2002-03-02 23:30:13

On Fri, 2002-03-01 at 15:18, David Abrahams wrote:
> 
> ----- Original Message -----
> From: "braden_mcdaniel" <braden_at_[hidden]>
> 
> > > That's not a very smooth solution for those who need to test against
> > > multiple versions.
> >
> > Such persons are the minority. It is better to make their lives a
> > little more difficult than to make the lives of everyone else much
> > more difficult.
> >
> > What other libraries use a scheme like Rene suggested?
> 
> Python does something similar.

The strategy is particularly useful when it is anticipated that users
may need to have multiple versions of binary packages concurrently
installed.

> > These issues with deployment aren't new, and they certainly aren't
> > unique to Boost. Why are novel solutions being proposed?
> 
> Why do you say "novel"? It's not as though these ideals are local
> inventions. Rene's suggestion is taken from other *nix libraries and tools
> we've seen where versioning counts.

Come now, there are *plenty* of projects where "versioning counts" that
don't take such extreme measures.

In general, projects have a "development mode" where compatibility is
not guaranteed from release to release. Eventually the feature set is
resolved, things stabilize, and ultimately a release is made against
which binary compatibility is guaranteed for future releases in that
"product line". The project may go back into development mode; and at
that time, if it is appropriate to accommodate concurrent installations
of the old product and the new product, such strategies as incorporating
the version number into the product identifier may be appropriate.

But Boost is in that initial development mode. There has never been a
product line established for which there has been any kind of guarantee
of "maintenance releases". Thus the requirement to segregate Boost's
releases as described is questionable.

Furthermore, incorporating version numbers into the directory structure
makes sense only when those numbers can be used to distinguish
compatibility. But Boost has lots of parts--many of them distinct--and
users may only use a few of them. For a given library within Boost, the
overall Boost version number is not usefully informative as to the state
of compatibility with a previous release.

I think incorporating the Boost version number into the directory
structure complicates deployment, and accomplishes very little.

> > > Having a version number under a common prefix really
> > > simplifies configuration: it means you don't need to explicitly
> > specify an
> > > installation directory for each version you want to test against.
> >
> > Testing against multiple versions of Boost is definitely an edge case.
> 
> Since it appears we can make everyone happy using symbolic links, do we
> really have to choose?

I think it is appropriate to question whether the edge case you describe
*really* warrants complicating deployment.

-- 
Braden McDaniel                           e-mail: <braden_at_[hidden]>
<http://endoframe.com>                    Jabber: <braden_at_[hidden]>