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 19:09:04

On 13/05/15 06:43 PM, Michael Ainsworth wrote:
> As previously mentioned, git submodules can help track dependencies, and this could be used advantageously.

git submodules only address a tiny part of the dependency tracking
problem. In fact, the entire modularization effort has been very
narrow-minded until now, focusing exclusively on reducing dependencies
between source code, neither projects nor (binary) packages.

> For example, say there is Boost.ProjectA located at git_at_[hidden] <mailto:git_at_[hidden]>:Person_A/Boost.ProjectA.git which depends on Boost.ProjectB located at git_at_[hidden] <mailto:git_at_[hidden]>:Person_B/Boost.ProjectB.git. If ProjectA 1.2 requires ProjectB 3.4, then ProjectA can simply specify that as a submodule.

What problem does that solve ? ProjectA is still tightly coupled to
ProjectB. Both are still built together.

>  That part is simple. The complicated part is configuring all the dependencies of all the components within Boost.
>
> So is it possible that an umbrella project located at git_at_[hidden] <mailto:git_at_[hidden]>:Admin/Boost could reference both submodules?

Again, what problem would that solve ? You would likely have to
reference specific versions of those submodules (such as HEAD, or
specific branches / tags), which is exactly what I think we should move
away from.

>  In such a case, the release process would have to undergo changes, such as follows:
>
> The (example) Umbrella Boost project is at 2.0 and 2.1 in the works.
> Person B informs Admin that there are significant improvements in Project B version 3.5, and he wants them included in the upcoming Umbrella 2.1 release.
> Admin knows that Project A depends on Project B, and so informs Person A that they are required to ensure Project A is compatible with Project B version 3.5 in order to be included in the Umbrella 2.1 release before date X.

Right, which is a good argument not even to attempt such a centralized
project synchronization.

> If Project A is not compatible by date X, one of several options could occur:

[...]

Instead, let ProjectA express its dependency on ProjectB (including any
version range) both, in the docs, as well as in the build tools (so the
proper checks can be done. Again, it would certainly be helpful to
provide tools (part of boost.build) to make it convenient for library
authors to encode such dependencies as build checks. But there should be
no requirement for anyone to use those tools.

Again, all of this has already been solved many times, so there is no
need to reinvent any of those wheels within Boost. It's just a
distraction on many levels.

        Stefan

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