On 18 June 2017 at 23:34, Edward Diener via Boost
When I speak of dependencies I am not just speaking of library X depending on other libraries A, B, and C etc. I am also speaking of library X depending on particular versions of library A, B, C etc. But since the only versioning system Boost has is a single version number for a Boost release, and since their is no way a library can check even that single version number of a Boost release either at compile or run-time, Boost libraries have no way to check versioning of other individual Boost libraries on which a library may depend.
If you say, I am going to distribute my library X with particular releases of library A, B, and C etc. with which I know my library X will work correctly you then have end-users of your library who may have multiple copies of libraries X, A, B, and C etc. on their systems, ...
and: Robert Ramey wrote: "In order to distribute boost as individual libraries as opposed to a monolithic set, individual library versioning will sooner or later have to be adopted." This is exactly how rust's Cargo works. Developers can specify the version or version+ against which his library should be built. I'm not claiming Cargo is perfect, but it's really pretty good at this and creates complete transparency as to what the dependencies are. Having multipple versions around is a consequence of this though. Cargo just works! Bar errors that did not came out in testing, this guarantees stability for every library individually, which in its' turn guarantees overall stability. This is pretty neat!
Let's be realistic, this is a real problem which only some sort of Boost individual library versioning system for starters can hope to solve.
The build system should address/include the versioning, Cargo should be taken as a model, me thinks. degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798