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

From: Braden McDaniel (braden_at_[hidden])
Date: 2002-03-03 20:11:20

On Sun, 2002-03-03 at 11:36, Rene Rivera wrote:
> gtk+: /usr/include/gtk-1.2/gdk, /usr/include/include/gtk-1.2/gtk
> python: /usr/include/python1.5, /usr/lib/python1.5
> glib: /usr/include/glib-1.2
> 
> 1. How are those so different than my suggestion to make it novel?
> 2. How does the above not assume binary and source incompatability?

Your scheme encodes the micro version number in the name. None of the
above projects do that. There is no reason to encode this version number
in the name if you are not going to break compatibility when it changes.

Indeed, there is no point in including *any* version number that does
not denote a break with backward compatibility. I am reasonably certain
that the aforementioned projects did not include the version number in
their directory names arbitrarily. Rather, it was done to denote a
stable release with which backward compatibility had been broken in
subsequent releases. Thus this was not a scheme defined up-front that
assumed compatibility would be broken; instead, it is the result of
planned, managed breaks with compatibility.

The problem with applying such a scheme to Boost at this time is
that--as I understand it--the Boost version number encodes no
information about backward compatibility (or a lack thereof).

> 3. How is it one can assume that different versions don't break compatability?

Because it's something that, in general, is avoided. Of course, it
depends on the status of the particular dependency. But in practice,
this tends to work pretty well for incremental updates.

> As a user, if a library my software uses changes version I would require
> testing against the new version, and then make another release using the new
> library.

That really depends on whether the dependency has broken binary
compatibility, doesn't it?

> This is not optional but a requirement, I would not want the users of
> my software to have to guess if the version of the libraries that they have is
> compatible with my software.

In general, there is a good faith assumption that if a dependency does
not claim to have broken compatibility, it has not done so. Yes, this
can break down. Usually it does not.

> 4. How can you guarantee that without explicit version numbers?

It depends on your particular needs. autoconf is capable of checking for
specific features (which is generally smarter, if less convenient, than
checking for a specific version number). With a little help from the
dependency, autoconf can check the dependency's version number: in the
past it was common to install a script that could tell users the version
number of a package; the modern thing to do is to use pkg-config for
this purpose.

> >> > 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.
> 
> 5. How is it that you want to consider different parts of Boost independant,
> and at the same time want a single Boost distribution?

I think it is definitely preferable to have a single source distribution
for Boost. However, it may be appropriate to partition a binary
distribution along individual library lines.

> 6. How would one indicate wether different parts of Boost have not broken
> compatability from a previous version?

There are a few commonly employed means:

        * autoconf tests can check for specific features of interest.
        * libtool library version numbers indicate the state of binary
          compatibility.
        * the individual libraries can be given their own revision
          numbers, which can be checked with pkg-config.

> >> > I think incorporating the Boost version number into the directory
> >> > structure complicates deployment, and accomplishes very little.
> 
> 7. How does it complicate deployment?

What I meant was it results in a deployment that is less straightforward
to understand. There is the issue of symlinks: should the installation
create them, or should they be created as needed by sysadmins? Whatever.
Once you have a symlink, you have multiple paths to the same file. Naive
developers won't necessarily know which they should use under given
circumstances. This can all be explained in documentation, of course;
but it has to be explained because it is more complicated.

> >> 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.
> 
> 8. If the non-developer user is a user of software developed, and that
> developer is a user of Boost. How does that change the version compatability
> requirements?

It doesn't.

> >> > > > > 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.
> 
> 9. Relelated to #7, which deployment does it complicate, that of Boost, or of
> software that uses Boost?

I think my answer to 7 covers this.

> >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.
> 
> 10. If it's a consistent, across versions, Boost deployment, how will it
> become less obvious?

The culprit is that there is no defined correlation between backward
compatibility and the Boost version number. Without defining that, you
cannot guarantee consistency: different versions *might* be compatible,
and they might not be. Fix that, and it begins to make sense to
incorporate the version number into the directory structure.

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