Re: [Monotone-devel] botan 1.7.3

[Zack Weinberg]

On Sun, Feb 17, 2008 at 9:26 AM, Markus Schiltknecht <address@hidden> wrote:
[...]
>  Doing that upgrade, I'm thinking again about the effort and benefits of
>  the integrated botan. How expensive would dynamic linking to the botan
>  library be? The trade off here is: maintaining our own set of changes
>  and configuration scripts vs maintaining compatibility to multiple botan
>  versions.
>
>  To make use of assembly optimized SHA1, we'd either have to add a
>  --with-system-botan, and rely on a hopefully optimized system library.
>  Or add our own architecture detection and conditionally add the most
>  fitting SHA1 assembler routines. I'm not sure what's easier to do. Any
>  strong opinions for either variant?

I've been thinking about this a bit myself, because the Debian
security people would really like us to stop using *all* of our
bundled libraries, so that when a security issue hits one of them they
can just upgrade the shared library and be done.

Also, hardcoding the configuration parameters for all the bundled
libraries doesn't just preclude use of Botan engines, it was the
proximate cause of some 64-bitness headaches with sqlite a while back
and a weird Windows issue with pcre that I still don't really
understand.  It would be nice to incorporate the upstream build
systems (and testsuites!) for the bundled libraries.

The vague plan I've got is to give each bundled library a top-level
directory which contains as near as possible a verbatim import of the
most recent upstream tarball.  Our own source code moves to a
subdirectory, and there's a top-level configure script that
coordinates building all the bundles that are not overridden by
--with-system-foo, then our own code.  This lets us use -I switches to
reference the headers for only those bundled libraries we're actually
using.  [Right now, for instance, I think we're getting the bundled
pcre.h even if we don't use the bundled library.]

zw