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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk