[bind10-dev] dependency on boost runtime libraries

[JINMEI Tatuya / 神明達哉]

At Wed, 24 Mar 2010 11:28:19 +0100,
Jelte Jansen <jelte at isc.org> wrote:

> > BTW, that's one of the reasons why I generally try to apply the pimpl
> > approach and hide standard/boost library dependencies in .cc from .h.
> > And, in this sense, one difficult part is boost::shared_ptr.  We are
> > currently heavily using shared_ptr objects in public interfaces, and
> > it seems to me not trivial to hide them within the actual
> > implementation.
> 
> Good point, but with Boost I think this is less of a problem if we keep
> it header-only, and those headers included in our own release; as long
> as we have abstracted away from the name boost::shared_ptr (by defining
> FooPTR everywhere), *and* we control the headers that define them
> ourselves, should they ever change we can update the definitions we made
> at the same time as we update the included headers (by replacing the
> typedefs).
> 
> I should hope STL is stable enough to be used for this.

Hmm, maybe we are talking about slightly different types of ABI.  You
seem to focus on the interface between BIND10 and external packages
that BIND10 uses (either binary or headers); I also meant the
interface between BIND10 and third-party applications *that use
BIND10*.

Consider the case where a user installs a binary (+ headers) form of
BIND10 package and tries to develop an application using it.  Since
"FooPTR" would be a typedef of boost::shared_ptr<Foo>, they'll need to
include the corresponding boost header files as well as
"isc/bind10/foo.h".  But the boost versions may be different for the
BIND10 binary and for the developer's environment (or even if it's the
same other build environment such as the compiler may be different),
so the binary representations may also differ in the BIND10 binary and
the developer-compiled objects.

In theory STL and other standard library (non builtin) objects have
the same problem, although it's probably much more stable than boost
in practice as you said.

There are several approaches to deal with this case:
- provide the boost header files we use to build the BIND10 binary
  as well as the BIND10's own header files
- declare that we don't support (or guarantee) this type of
  compatibility
- hide any non-builtin types from public interfaces (or provide
  equivalent interfaces only using builtin types)

Each has its pros and cons.  We'll eventually have to make a decision,
but it'll probably a bit later phase of the development when we have
more complete set of features.

---
JINMEI, Tatuya