[bind10-dev] dependency on boost runtime libraries

[JINMEI Tatuya / 神明達哉]

At Tue, 23 Mar 2010 16:56:12 +0100,
Jelte Jansen <jelte at isc.org> wrote:

> so right now, if I'm not mistaken, we need a runtime libboost for two
> specific reasons; asio and python wrappers.

That's basically correct.  (To be very precise, boost::system on which
the Boost version of Asio relies.)

> I have said this before, but let me restate; think we should reconsider
> this. Either we go all the way or we keep the boost dependency on
> header-files only.

First off, I didn't intend to add the dependency as a given decision.
It was a kind of workaround to provide necessary features for the
year1 release as quick as possible.  I don't know how exactly
Boost.Python was introduced, but my understanding is that it's also an
experimental attempt.

> In the first option we remove the other TCP implementation from the
> sources, and make it a hard dependency. This has the advantage of
> getting the other runtime library (libboost-python) for 'free', but we
> do rely on an external dependency, even for the core system (as opposed
> to, say, the current dependency we have on sqlite3, which is both only
> for b10-auth, but in the future even only for one specific datasource
> backend, and hopefully even optional within that one, but that is
> another discussion).

In general, I tend to agree that it's better to minimize external
dependencies because they generally raise the bar for the users to
introduce BIND10.

But at the same time, my understanding of one of the basic development
policies for BIND10 is to avoid the NIH syndrome (unlike BIND9).
These two policies often conflict.

So we need to have some more specific policies of when we should
accept external dependencies and when we should avoid that even if it
results in reinventing a wheel.  Right now I don't have a clear
proposal, but as you hinted I can think of several 

- whether it's part of the core system that (nearly) all BIND10
  components use, or it's an optional feature.
- whether it requires a separate binary file or it can be mixed in our
  source tree (although except boost many external "libraries" would
  actually require binaries)
- whether it's generally available as part of the OS or can be easily
  added through a package system, or whether the user needs to take
  some tricky steps to build/install it.
- whether it's stable and/or well maintained or it's frequently
  changed and/or mostly dropped

Regarding the specific examples of boost::system and boost::python, my
personal experiences so far suggest they are too heavy to rely on, and
we should probably seek a way to avoid using them.

> Oh and now that I'm talking about this; we should also not expose boost
> in our own API; with that we cannot even guarantee ABI stability between
> our own versions.

Right, and if we care about ABI, we should actually not even expose
standard library types (e.g. std::string) or at least we should
provide equivalent interfaces that only use plain old data types.

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.

---
JINMEI, Tatuya