Re: [boost] RE process (prospective from a retired FreeBSD committer)...

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

At Mon, 31 Jan 2011 13:20:28 -0500,
Edward Diener wrote:
> 
> On 1/31/2011 10:22 AM, Dave Abrahams wrote:
> > 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.
> 
> Not correct that some form of dependency checking "are not practiced
> by the many other projects that include such dependency
> relationships."

I didn't say that either.  I asserted that the specific list of forms
of dependency checking you mentioned are not practiced in general.  I
should have added "in my experience."  Of course I could be wrong, but
I haven't seen it.

> > 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.
> 
> Do you think that some form of programatically checking dependencies
> between modules should exist in a modularized Boost ? 

Yes

> >> 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.
> 
> I would be interested in how Ryppl plans to do this. Are there
> presently docs about this for Ryppl ?

Current plans are to leverage libsatsolver for this purpose.  No docs
available from Ryppl, but feel free to search the ryppl-dev list on
Google groups.

> While some form of header file dependency checking has never been
> popular, this has been largely due, I believe, to the fact that
> nearly all separate libraries are distributed in the form of shared
> libraries with version information. In C++ template programming this
> is not the case, so my suggestion about a form of header file
> dependency checking was meant to cover this area. 

It's a good idea, really!  I just don't see it as an absolute
requirement, which is what you seemed to be saying.

> But I am certainly willing to hear your, or anybody else's, better
> ideas. I just feel, as an end-user, that going from the current
> monolothic Boost to a modularized Boost will produce serious
> headaches if libraries are not in sync when an end-user attempts to
> use them for his product. 

Agreed.  The ryppl tool can manage that when you ask it to
fetch/install modules and their dependencies, and it must.  Some kind
of compile-time check in header files, like you suggest, would be a
bonus.

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