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

From: Rene Rivera (grafik666_at_[hidden])
Date: 2002-03-03 11:36:15

On 2002-03-03 at 10:09 AM, braden_at_[hidden] (Braden McDaniel) wrote:

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

No, the point to my posting was to suggest something and have users, like you
and others, indicate wether it was a workable solution. There was an implied
requirement that said users would suggest alternatives when they indicated
displeasure with the solution. That is, I wanted, and still want, constructive
feedback.

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

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?

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

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

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

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

>> > 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?
6. How would one indicate wether different parts of Boost have not broken
compatability from a previous version?

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

7. How does it complicate deployment?

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

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

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

-- grafik - Don't Assume Anything
-- rrivera_at_[hidden] - grafik_at_[hidden]
-- 102708583_at_icq - Grafik666_at_AIM - Grafik_at_[hidden]