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: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2015-05-13 18:08:23

On Wednesday 13 May 2015 17:30:48 Stefan Seefeld wrote:
> On 13/05/15 05:24 PM, Andrey Semashev wrote:
> > On Wednesday 13 May 2015 14:42:43 Stefan Seefeld wrote:
> >> 
> >> 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 realistically
> > have a zoo of tools used by different libraries and expect them all work
> > 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 pretty 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.

A Linux-based system relies on a single package management tool used 
throughout the system. There are multiple helpers for building packages 
compatible with that tool but these are just that - helpers, integration glue 
which basically boil down to the same scripts, configs, etc. which are 
compatible with that underlying packaging tool. Take dpkg and debhelper as an 
example. The latter provides a multitude or perl scripts which help building 
packages from very different sources but you have to deal with stuff like 
debian/control anyway. And this toolset doesn't even begin to solve the 
problem of building the dependencies of the package - this task is solved on a 
higher level with something like OBS or Launchpad. And to top that, this whole 
infrastructure is basically Linux-specific - a portable system with similar 
capabilities is a different story (ryppl?).

The bottom line is that the choice is already made on the Linux distro level. 
The same would happen on Boost level. Only someone would have to write that 
packaging tool and all the integration glue. Or just take and use something 
that already exists.