Re: [boost] Some statistics about the C++ 11/14 mandatory Boost libraries

Subject: Re: [boost] Some statistics about the C++ 11/14 mandatory Boost libraries
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-05-13 14:23:17

On 5/13/2015 1:52 PM, Stefan Seefeld wrote:
> On 13/05/15 01:00 PM, Edward Diener wrote:
>> On 5/13/2015 12:37 PM, Stefan Seefeld wrote:
>>> On 13/05/15 12:19 PM, Niall Douglas wrote:
>>>> Personally speaking, I think the new library authors are
>>>> overwhelmingly voting for a complete break with Boost 1.x. It makes
>>>> no sense to bundle these new libraries into a 1.x monolithic distro
>>>> when they have no dependencies on Boost.
>>>>
>>>> I believe now is the time we start establishing the infrastructure to
>>>> shape the new Boost 2.0 distro instead of wasting resources on trying
>>>> to refactor the 1.x distro. APIBind is there for maintainers wanting
>>>> to be part of both distros. Let's make a clean break.
>>>
>>> Allow me to bring up a point I have been trying to make for quite a
>>> while: Why does Boost need a single "distro" ?
>>> Assuming a full breakup of boost libraries with well documented (and
>>> encoded) dependencies among them, I think a much more viable solution
>>> for everyone would be to let each boost library become its own project
>>> with its own release schedule etc.
>>>
>>> So Boost would be merely an umbrella organization, and what you call a
>>> distro may be the repository of Boost libraries.
>>>
>>> Wouldn't that be something worthwhile to think about and discuss ?
>>
>> It is definitely worth discussing. The key is "with well documented (and
>> encoded) dependencies among them".
>>
>> How do we do this ?
>
> Glad you asked. :-)
>
> I think the answer is easy within the context I brought this up in:
> Niall is suggesting a clean break, with only little concern for any
> transition (refactoring).

I don't know what this means. No one can be serious that Boost libraries 
must be designed with no dependencies on other Boost libraries.

> So, if we start by assuming that each prerequisite library lives in a
> separate space, we can code these assumptions right into the build logic
> (e.g., separate header include and library search paths for each, etc.)
>
> Likewise, documenting the prerequisites is easy, if you have to do it
> upfront. It's only hard if these dependencies are implied, and only
> after the fact you need to re-discover them.

It's not documenting the prerequisites ( by which I assume you also mean 
library dependencies ), it is determining what versions of which 
dependence library a given library will need.

>
>>
>> It is silly to suppose that new "Boost" libraries will be developed
>> that do not depend on other already existing Boost libraries. If
>> library X depends on library Y we currently know that library X will
>> work with library Y for Boost distro N because we have tested them
>> before we release distro N. If library X goes off with its own release
>> schedule how do we determine with which versions of Y it will work
>> when it is being released ?
>
> That's for each library maintainer to determine and to encode. Of
> course, I would assume boost to provide shareable tools to make it
> easier to do this, but boost is hardly the only project facing such
> tasks. In fact, the entire Free Software world had to solve this for
> many years.

Sorry but that is just skipping over a real problem. If there are 
solutions that solve the problem then Boost needs to adopt one of those 
solutions. Having the solution be that each library developer specify in 
its documentation which library dependencies and which versions of those 
library dependencies the particular library works with is not solving 
the problem IMO.

> (I can think of ways to add support for expressing and checking right
> into boost.build, for example, but no boost library author should be
> forced to use any of those. It's merely a convenience to make their life
> easier, not harder !)