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: Stefan Seefeld (stefan_at_[hidden])
Date: 2015-05-13 14:42:43

On 13/05/15 02:23 PM, Edward Diener wrote:
> 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.

At least I never suggested no dependencies.

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

Yes. That's a solved problem (if you look outside boost), with many
solutions available, so I don't want to get into a discussion of which
tool is best. Boost has been suffering from way too many of those
discussions already.

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

I strongly disagree. "Boost needs to adopt" already sounds very wrong to
me, in the context of my proposal where Boost is little more than an
umbrella org.

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

It's not merely a question of documenting it (though that's certainly
part of it). It's also a matter of encoding those dependencies in the
build system, for example by using some validation checks that make sure
the actual version V of prerequisite library L meets the version
requirement.

But again, all I'm hoping for is to find tools that make my life (as a
library author) easier. Being forced to adopt a specific solution just
because some Boost admins have decided that that's in my own best
interest is heading in a very wrong direction.

        Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...