Nevin Liber wrote:
On 1 December 2011 14:29, Robert Ramey <ramey@rrsd.com> wrote:
a) libraries are modular. c) Libraries would be updated/versioned on their own schedule.
So how do you solve the versioning problem?
If Boost.Thread.90 requires Boost.SmartPtr.76 and Boost.Filesystem.90 requires Boost.Smartptr.77, you've got a usability nightmare on your hands. I don't see any way around Boost libraries having to work together in all baseline releases (which is what we have now).
I did consider this some time ago. I proposed something on this list. I forget the details right now but basically it would be along the lines of each library being able to report it's version at compile time and execution time. Libraries which use other libraries would be able to check that their requirements are met by inquiring this API. I believe that something similar - though likely more elaborate is ipmlemented as part of COM on windows to address the "DLL hell" issue. When I proposed this before, the consensus was that such as system wasn't necessary. I didn't really buy this but I other stuff to do so I just dropped it.
And this is a practical problem, as I have yet to work anywhere that doesn't have this problem when they integrate libraries from more than one source.
Hmmm - I have to address this all the time. If I make even a relatively simple Ap it might use the msvc C++ library, some version of the STL library, some version of SQL server and some version of windows. Then there might be some DLLS for special controls or whatever. All of these components have their own versioning. We don't demand that all these be deployed as a monolithic group. If we have to deploy a group of components together, we're really saying that the compoents are coupled together in their implementation which is basically an error. And this has already occured with parts of boost. ASIO, spirit, GIL and who knows what else were deployed separately before becoming part of boost. A requirement to deploy/version them concurrently isn't necessary nor is it convenient. And it's not pratical in the long run as it can't scale. Robert Ramey