[bind10-dev] dependency on boost runtime libraries

[Jelte Jansen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

JINMEI Tatuya / 神明達哉 wrote:
> 
> 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*.
> 

actually I was too, but even I didn't realize the full scope of the problem yet,
thanks :)

> 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.
> 

right, i guess it's even worse (what if both our lib and their app *are*
compiled on the same system, but the included headers have changed?)

> 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.
> 

right

> 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

yep, I think i was working to this approach, but I'm not sure whether that's
desirable or even feasible.

> - declare that we don't support (or guarantee) this type of
>   compatibility

Can we? Does boost have any form of stability guarantee?

> - hide any non-builtin types from public interfaces (or provide
>   equivalent interfaces only using builtin types)
> 

IMHO, this is the path we should take (and then we still have to decide on
header-only or not and whether to supply those headers :) )

> 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.

Well, I'm afraid that if we don't deal with this sooner rather than later, the
problem creeps into every corner...

Jelte

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkuqbzQACgkQ4nZCKsdOncUXUQCgrbHO9vnJUsnuS95RF6FRfZdN
bJQAn38aCMR1ph79u+bTsmAD6FetmmTJ
=wKSL
-----END PGP SIGNATURE-----