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-30 22:06:07

On 1/30/2011 8:33 PM, Dave Abrahams wrote:
> At Sun, 30 Jan 2011 16:11:51 -0800,
> Steven Watanabe wrote:
>>
>> On 1/30/2011 2:16 PM, Dave Abrahams wrote:
>>
>>> For me personally, Boost's monolithic structure takes much of the
>>> fun out of working on it.  Totally subjective and un-provable, I
>>> know.
>>
>> I don't get it.  I just don't get it.  What
>> is so hard about finding the directories for
>> the library that you're working on and ignoring
>> everything else?
>
> I didn't say it was hard.

There is another issue with Boost's structure which has little to do 
with library developers. Boost, after all, is for end-users also. Many 
end-users, whether rightly or wrongly, want to distribute with their 
product only those libraries ( header files, shared libraries, 
miscellaneous files ) that they need and Boost working on an all or 
nothing basis inhibits that, although it provides greater stability that 
way. While BCP might work fairly well, I believe it is hardly foolproof, 
whereas some means for being able to easily get just those Boost 
libraries, with their dependencies, which an end-user needs should be 
doable in a future vision of individually maintained/distributed Boost 
libraries.

On this basis my own concern, whether a DVCS is used or not, is the 
dependencies between libraries. With different versions of different 
libraries existing, within there own distributions, it is absolutely 
necessary that the dependencies between different versions of libraries 
be resolved correctly. While this is not overwhelmingly difficult, it 
needs to be done in a way that is transparent as possible and provides 
the least problem for end-users, else no one is going to want to deal 
with the headaches involved on a practical basis. 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.

Just thought I would mention this minor fact <g>.