Re: [boost] Development and Release Practices

From: David Abrahams (dave_at_[hidden])
Date: 2007-08-08 13:02:39

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