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

From: Braden McDaniel (braden_at_[hidden])
Date: 2002-03-03 10:09:16

On Sat, 2002-03-02 at 23:54, David Abrahams wrote:
> 
> ----- Original Message -----
> From: "Braden McDaniel" <braden_at_[hidden]>
> To: <boost_at_[hidden]>
> Sent: Saturday, March 02, 2002 11:30 PM
> Subject: Re: Installing Boost (WAS: Re: [boost] Re: Why Jam?)
> 
> 
> > 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.
> 
> Awfully combative, aren't you?

It seems to me as though a lot of proposals and discussion have gone on
in these threads without being sufficiently informed by the state of the
art. There has been the presumption of many problems, some of which do
not exist and some of which are inconsequential to all but a small
minority. I feel that at this point further discussion is not very
useful. If this project is to be pursued, it is time to put something in
CVS and then see what problems need to be resolved.

> I didn't say the idea came from looking
> at every single project where versioning counts and noticing that they
> all do it this way. All I suggested was that it's not a novel idea;
> there is precedent. Instead of answering my question about why you're
> calling it "novel", you're now calling it "extreme". So now I have two
> questions: why does Rene's idea seem "novel" and "extreme" to you? There
> certainly are a number of open-source projects that work this way.

I find it novel because I do not see a single other package on my Linux
system that works as described. Python included. Python includes the
major and minor version number in its directory name. It appears to do
this to *denote* binary incompatibility (rather than assume it, as the
proposed scheme would do).

It is extreme because it assumes compatibility will be broken on *every*
release.

> > 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.
> 
> I don't think it's a requirement, just an idea which some happen to find
> appealing. It seems potentially useful and relatively non-intrusive. Is
> there a downside?

The potential for gratuitous source level incompatibility comes to mind.
Naive projects may include files associated with a specific version when
they really don't need to.

> > 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.
> 
> Not by iteself, but it does tell you something definite about the state
> of the library.

What's that? The Boost version number doesn't encode any information
about source or binary compatibility. (Or does it?)

If my interest is in specific libraries within Boost, the information
that Boost as a whole has advanced is of very little use to me since I
cannot easily determine the relationship of that advance to a specific
library.

> > I think incorporating the Boost version number into the directory
> > structure complicates deployment, and accomplishes very little.
> 
> I know it will make my life a little more convenient.

Could you elaborate?

> How does it
> complicate deployment? Is this really worth arguing over?

From my perspective it's a design philosophy issue. I don't like the
idea of cluttering the include directories with directories that aren't
really necessary. I don't think the average non-developer user is likely
to require more than one Boost version to be installed--especially under
the same prefix. And deployment issues should be resolved primarily with
those users in mind, since they make up the majority.

> > > > > 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.
> 
> I guess the answer depends on whether it really does complicate
> deployment, and by how much.

The complication to the automake scripts would not be too great. I worry
more that the Right Way to use the library would become less obvious to
users.

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