[bind10-dev] dependency on boost runtime libraries

[Jelte Jansen]

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

On 03/24/2010 08:40 AM, JINMEI Tatuya / 神明達哉 wrote:
> 
> 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.
> 

Right, I'm not saying that these were bad choices (in fact I quite agree
with them), I'd just like to see us make a conscious decision about this
before it creeps into too many places and we don't really have a choice
anymore :)

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

ack, agree on the bullet points you put (which i snipped), in any case
it's going to be a separate decision every time, and we mostly need to
make sure each one is thought out, and documented.

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

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.

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

iEYEARECAAYFAkup6UMACgkQ4nZCKsdOncX+iQCg0px9fUea0zTGPMyO+Uw6/6MC
xmEAoJSQCa+EvSRbp1JOBPEIrdq1JNlE
=OgEQ
-----END PGP SIGNATURE-----