on Wed Aug 08 2007, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
David Abrahams wrote:
on Wed Aug 08 2007, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
Then, as with the Python library, we have the opposite problem: most other libraries are dependent upon Serialization.
Hmm "we"?
Umm, yes. Like it or not, we're all in this together. Dependencies can cause problems for the maintainers at both ends of the relation.
I would say that if that is a problem, it would be the problem of the library maintainer and he can/will decide how much he wants to depend on another library. I don't see the serialization library any different than any other library in this regard.
It's very different, because it's not an implementation detail. If I write a library of containers, nobody will come to me complaining that "your library doesn't support type_traits." They are likely to complain that I don't support Boost.Serialization (or Boost.Python).
Of course if the library maintainer wants to make serialization of his types an optional part or of his library he's free to do so using a command line arguement to bjam or whatever. But still - its up to him -
Of course it's up to him. Who implied otherwise?
its not a boost problem.
When it becomes an issue that many library authors have to deal with, it becomes a Boost problem. If everybody deals with it in a unique way, we will have more problems than if we have a coherent pattern to follow that minimizes release and testing problems.
In reality, python bindings and serialization code are separable and optional parts, and we ought to have some way to treat them as such from the point of view of the testing and release processes.
Most of the other libraries which contain serialization code have a separate (and optional) header for it (similar to the headers in the serialization library for stl collections) so I don't think there is a lot to be concerned about here.
If serialization and python become "prerequisite libraries" just because other libraries "depend" on them, that's a big problem. These problems are not insurmountable, but they deserves attention. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com