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

Subject: Re: [boost] RE process (prospective from a retired FreeBSD committer)...
From: Edward Diener (eldiener_at_[hidden])
Date: 2011-01-31 13:20:28

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

Do you think that some form of programatically checking dependencies 
between modules should exist in a modularized Boost ? If not do you see 
a manual form of checking dependencies to be the only way, or do you 
feel that no form of checking dependencies is necessary ?

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

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

I admit my background in Windows programming and my more limited use of 
Linux shows me that a programmatic method of dependency checking would 
be very valuable. 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. 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. This is especially true of 
potentially individual Boost libraries which are released at their own 
pace with new functionality being periodically added and fixes being made.

I am sure you know all this, but sometimes developers do not focus on 
end-user problems because they are so keen on the programming task they 
do within their own development.