At Mon, 31 Jan 2011 13:20:28 -0500, Edward Diener wrote:
On 1/31/2011 10:22 AM, Dave Abrahams wrote:
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.
Not correct that some form of dependency checking "are not practiced by the many other projects that include such dependency relationships."
I didn't say that either. I asserted that the specific list of forms of dependency checking you mentioned are not practiced in general. I should have added "in my experience." Of course I could be wrong, but I haven't seen it.
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.
Do you think that some form of programatically checking dependencies between modules should exist in a modularized Boost ?
Yes
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.
I would be interested in how Ryppl plans to do this. Are there presently docs about this for Ryppl ?
Current plans are to leverage libsatsolver for this purpose. No docs available from Ryppl, but feel free to search the ryppl-dev list on Google groups.
While some form of header file dependency checking has never been popular, this has been largely due, I believe, to the fact that nearly all separate libraries are distributed in the form of shared libraries with version information. In C++ template programming this is not the case, so my suggestion about a form of header file dependency checking was meant to cover this area.
It's a good idea, really! I just don't see it as an absolute requirement, which is what you seemed to be saying.
But I am certainly willing to hear your, or anybody else's, better ideas. I just feel, as an end-user, that going from the current monolothic Boost to a modularized Boost will produce serious headaches if libraries are not in sync when an end-user attempts to use them for his product.
Agreed. The ryppl tool can manage that when you ask it to fetch/install modules and their dependencies, and it must. Some kind of compile-time check in header files, like you suggest, would be a bonus. -- Dave Abrahams BoostPro Computing http://www.boostpro.com