
At Mon, 31 Jan 2011 09:54:23 -0500, Edward Diener wrote:
On 1/31/2011 12:38 AM, Dave Abrahams wrote:
At Sun, 30 Jan 2011 22:06:07 -0500, Edward Diener wrote:
On this basis my own concern, whether a DVCS is used or not, is the dependencies between libraries.
...
This means some way of incorporating version information in header files, some way of incorporating version information in shared libraries, some way of checking both transparently, and all of this must work in whatever environments a future individually distributed Boost targets.
Those are all "nice-to-haves" that are not practiced by the many other projects that include such dependency relationships. Care to design that system?
If this is not practiced by many other projects, perhaps that is because there are few other projects potentially seeking to deliver their libraries separately. But of course I think you are not entirely correct as the various problems of DLL dependencies on Windows and the tools on Linux to resolve dependencies when upgrading some application on Linux show.
I'm not correct about what? I never denied that problems arise.
I would only seek to design such a system if there would be felt a need to do so by others also. In the face of "nobody else finds a need to do this so why should we" why would I expend my energy designing such a system or discussing it with others ?
You complete misinterpret me. I totally understand _why_ we should design such a system, and, as I said, I think it would be really nice to have. I just don't think we need "some way of incorporating version information in header files, some way of incorporating version information in shared libraries, some way of checking both transparently, and all of this ...work[ing] in whatever environments a future individually distributed Boost targets" in order to move forward with modularization. These are independent problems that can be solved independently. In fact, people already have these kinds of issues with a non-modularized Boost, so it would be good to solve them today.
I will only offer that if Boost does in the future decide to deliver individual libraries rather than a single monolothic distribution as it does now, that end-users finding that library X version N.N does not work with library Y version N.N, of which it has a dependency relationship, will not be happy campers.
Encoding version dependency metadata and using it to make sure a coherent set of interoperable libraries are used together is a basic, fundamental requirement of Ryppl. However, I never envisioned it involving any of the things you listed above. Again, though, that would be really nice to have, and I'd like to see such a system. -- Dave Abrahams BoostPro Computing http://www.boostpro.com