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