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"? 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. 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 - its not a boost problem.
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. Robert Ramey