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@github.com mailto:git@github.com:Person_A/Boost.ProjectA.git which depends on Boost.ProjectB located at git@github.com mailto:git@github.com: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@github.com mailto:git@github.com: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...