Subject: Re: [boost] Some statistics about the C++ 11/14 mandatory Boost libraries
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2015-05-13 18:09:05
On 13/05/15 06:00 PM, Edward Diener wrote:
> On 5/13/2015 5:30 PM, Stefan Seefeld wrote:
>> On 13/05/15 05:24 PM, Andrey Semashev wrote:
>>> On Wednesday 13 May 2015 14:42:43 Stefan Seefeld wrote:
>>>> On 13/05/15 02:23 PM, Edward Diener wrote:
>>>>> On 5/13/2015 1:52 PM, Stefan Seefeld wrote:
>>>>>> 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.
>>> I think you will have to make a choice ultimately. You can't
>>> have a zoo of tools used by different libraries and expect them all
>>> together nicely. If library A uses a dependency tracking tool X and
>>> depends on
>>> library B then X should be able to handle dependencies of B as well
>>> and so on
>>> to the leaf dependencies. I'm pretty sure the same would be desired
>>> for other
>>> tools, like build systems. If it doesn't work that way then you can
>>> much drop the whole idea of modularity and follow the path of
>>> copy/pasting the
>>> code, something Google likes to do.
>> Just look at a typical Linux-based software stack. There are lots of
>> applications with lots of dependencies, with lots of different choices
>> of choices for tools to build and package, as well as version-control
>> the code. Sure, life would be easier of the whole world would agree on a
>> single set of such tools. But that isn't realistic. And experience with
>> Boost has shown that the community easily gets distracted by bikeshed
>> discussions about which tools to pick, which policies to adopt, etc.
>> That problem can easily go away if there is no single choice to be made.
>> In other words, "modularity" needs to be applied not just the code but
>> the organization, too !
> On Linux systems there is always dependency management software which
> specifies that if package X of a particular version is installed all
> dependent packages of the correct version are also installed. These
> systems do not depend on some documentation which tells the end-user
> what has to be done manually to install a package.
> Of course most packages can be built from source manually, but the
> most Linux users probably use the automated package management systems
Right. What's your point ?
> If Boost goes the way where individual libraries can be released
> separately on their own development cycles, as you suggested, I think
> some sort of agreed upon automated dependency management system needs
> to be in place, at least for dependencies between Boost
It surely would be convenient for developers to be able to handle
dependencies, which is why I suggested that something like boost.build
adds ways to express (and validate) them. But I'm still not sure why you
would want to mandate that. It really is the same question as with all
the other tools.
Just look at the never-ending discussion about using bjam vs. cmake. I
just don't have any hope that the entire (growing) boost community will
ever agree. Letting each project decide for itself which tools work best
seems to me to make most sense.
-- ...ich hab' noch einen Koffer in Berlin...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk