Re: [boost] [modularization] Are modular releases a goal or a non-goal?

Subject: Re: [boost] [modularization] Are modular releases a goal or a non-goal?
From: Thijs van den Berg (thijs_at_[hidden])
Date: 2014-09-22 06:24:19

On Mon, Sep 22, 2014 at 10:53 AM, Stephen Kelly <hello_at_[hidden]> wrote:

> Thijs (M.A.) van den Berg wrote:
>
> > Now it has grows into a
> > large set of libraries for specific niches with varying level quality
> > (code, docs, maintenance support)
>
> Really? Is that what it is?

Are you sure?

All statement are my  my personal observation and opinion.  It's how I
experienced the evolution of boost as a long time boost user. I want to
share my opinion and be constructive. In this reply it's again my personal
opinion so please be easy on me? (think of every sentence ending with IMO).
I'm also certain that my opinion about aspects will change once I learn
about aspects I currently have not thought about.

> Or is that a goal you have in
> mind? Is that what boost was while it was in svn? Or did boost become that
> by migrating to 100 *interdependent* git repos? Did migrating to 100
> *interdependent* git repos help the above statement in any way?
>
I'm talking about the set of libraries that are part of boost not about the
distribution form.

A goal I have in mind is to give individual libraries clear personal
identities and allow for fragmentation of boost.The current modularization
could have a goal like that. Libraries already try to have personal
identies. They are listed as a list of libraries, they sometimes have
creative names instead of generic descriptive names.

>

> > , and perhaps varying levels of language
> > support (C++14 only libs?) and modularization makes sense.
> >
> > Some examples of environment that have solved the issues of having large
> > sets of libraries with dependencies and various levels of quality: Debian
> > Linux, R project, python pip.
>
> Are you saying you want similarity to those projects from boost?
>
> Boost is released as one tarball, as I linked in the original post, and
> that
> is not going to change. Or it is not a goal to change that, apparently.
>

> In that monolithic light, please walk me through the analogy how current
> boost (or a boost you have as a goal) relates to Debian Linux, because I
> don't get it.
>
It would be nice if I could do:
> apt-get install boost-math
and that that would result in my machine downloading some boost libraries
so that I can use boost.math with my specific compiler on my specific
platform.
Part of the it is about a dependency tree,minimal requirements, but also
about configuration / versions. I would not like it to pull in *all* of the
boost respository. I imagine that at some point we could have e.g. a
Boost.Math for C++14 fork and If I said I wanted that, then I would *not*
get parts like <random> that have already been added to the standard. Boost
could also solve that by staying monolithic and providing switches or
include wrappers, but those solutions would be less intuitive.

>
> > Maybe we need an independent  "apt-get" like tool for C++ libraries? Not
> > just for boost libraries, but various other C++ libraries as well?
>
> Are you saying this should be a goal? Is a modular release of boost (a
> tarball per library) a prerequisite for that or not?
>
On second thought I thinh this could better be an independent tool for C++
developers who want easy management of 3rd party C++ libraries, ..but it
would benet from the modularization of boost. Maybe it doesn't need to be
anything new, maybe it could be apt as it is?

>
> Tell me how things are now in your words and tell me what your goal is.
>
> My goals would be change boost from a single entity "the boost libraries
bundle" to a platform hosting multiple identies "the platform where i can
find e.g.Boost.Math" because I think it will make it easier to contribute,
and easier to use. The most important change would be to change the single
identity of the whole of boost  (identity = the thing you install as a
user, the thing you need to learn to use, they think you asses the quality
of) to multiple indentities -one for each library of boost-.

In my opinion these are some direction we *can* take now that we have focus
on modularisation and dependency graphs

> Thanks,
>
> Steve.
>

Thanks for responding and asking for clarification,
Thijs