Boost logo

Boost :

Subject: Re: [boost] RE process (prospective from a retired FreeBSD committer)...
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-01-31 10:22:53


At Mon, 31 Jan 2011 09:54:23 -0500,
Edward Diener wrote:
>
> On 1/31/2011 12:38 AM, Dave Abrahams wrote:
> > At Sun, 30 Jan 2011 22:06:07 -0500,
> > Edward Diener wrote:
> >>
> >> On this basis my own concern, whether a DVCS is used or not, is the
> >> dependencies between libraries.
> > ...
> >> This means some way of incorporating version information in
> >> header files, some way of incorporating version information in shared
> >> libraries, some way of checking both transparently, and all of this
> >> must work in whatever environments a future individually distributed
> >> Boost targets.
> >
> > Those are all "nice-to-haves" that are not practiced by the many other
> > projects that include such dependency relationships. Care to design
> > that system?
>
> If this is not practiced by many other projects, perhaps that is
> because there are few other projects potentially seeking to deliver
> their libraries separately. But of course I think you are not entirely
> correct as the various problems of DLL dependencies on Windows and the
> tools on Linux to resolve dependencies when upgrading some application
> on Linux show.

I'm not correct about what? I never denied that problems arise.

> I would only seek to design such a system if there would be felt a
> need to do so by others also. In the face of "nobody else finds a need
> to do this so why should we" why would I expend my energy designing
> such a system or discussing it with others ?

You complete misinterpret me. I totally understand _why_ we should
design such a system, and, as I said, I think it would be really nice
to have. I just don't think we need "some way of incorporating
version information in header files, some way of incorporating version
information in shared libraries, some way of checking both
transparently, and all of this ...work[ing] in whatever environments a
future individually distributed Boost targets" in order to move
forward with modularization. These are independent problems that can
be solved independently. In fact, people already have these kinds of
issues with a non-modularized Boost, so it would be good to solve them
today.

> I will only offer that if Boost does in the future decide to deliver
> individual libraries rather than a single monolothic distribution as
> it does now, that end-users finding that library X version N.N does
> not work with library Y version N.N, of which it has a dependency
> relationship, will not be happy campers.

Encoding version dependency metadata and using it to make sure a
coherent set of interoperable libraries are used together is a basic,
fundamental requirement of Ryppl. However, I never envisioned it
involving any of the things you listed above. Again, though, that
would be really nice to have, and I'd like to see such a system.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk