Re: [Monotone-devel] 3rd party libraries

[Zack Weinberg]

On Thu, Oct 23, 2008 at 3:38 AM, Markus Wanner <address@hidden> wrote:
>  * libz: dynamic linking hasn't posed any problems and the library seems
> to be available on pretty much any system.

libz is a shining example of how to do library stability.  (It helps
that it hasn't needed to change in years and years except for the
occasional bugfix. :-)

>  * botan: source inclusion *has* posed problems in the past, namely that
> we couldn't use asm optimizations due running our own build harness for
> botan. Additionally, maintaining the build harness was a hassle and
> something I'm glad to get rid of. The library is still pretty new and
> not available on all systems. We are currently using a development
> branch (1.7), which is a bit unfortunate. However, I've adjusted
> nvm.stripped, so that it compiles against 1.6.x as well. I'm all for
> dynamic linking of that library.

I'm all for dynamic linking of botan, too, and being able to use the
accelerated engines.

>  * sqlite: source inclusion worked fine so far, but it hasn't really
> been updated for quite awhile. nvm.stripped provides dynamic linking,
> but SQLite also offers a pretty simple amalgamation release, which we
> could use as well. Offering choice between system library and bundled
> one should be simple enough to maintain, IMO.

So I believe this is the one that started graydon on the "bundle
everything" path, with specific point revs of sqlite 2.x working for
us and others not, and over at my day job we've been having similar
problems with more recent releases of it.  So it may well be worth
continuing to bundle a "known good" version of the amalgamation.  If
we do, though, we should be much more proactive about testing newer
releases so we don't wind up where we are now (i.e. stuck multiple
feature releases behind the curve) again.

>  * lua: pretty similar to sqlite, except the source inclusion variant is
> a bit more complicated. I'm all for dynamic linking and don't see much
> of a reason for source inclusion.

I think I mentioned this before, but if we're going to stop bundling
lua we have to overhaul the error-handling interface between lua and
our code, because we're currently relying on lua's ability to be
compiled as C++ and use C++ exceptions to report errors.  Of course we
need to overhaul it *anyway* because right now lots of errors just
silently get lost, but remember that this is on the critical path for
unbundling it.

>  * pcre, idna: I'm not too sure about these, but dynamic linking seems
> to make more sense. I didn't hit any stumbling block so far in nvm.stripped.

Concur.  API/ABI stability shouldn't be an issue with these.

>  * boost: we've done quite a lot of work to get rid of boost and
> replaced it with our own code.

Discussed in other message.  I'd forgotten about boost::test, but it
was another case of the wrong abstraction for our needs; in particular
it was really painful integrating it with our I(), E(), etc macros.

> If not, we need to decide if we want to re-add boost::date_time to
> replace our own date handling code. mtn-dates.o from nvm.dates is
> currently 89 KiB on my 64bit machine, while the boost::date_time .so
> file weights only 60 KiB (presumably lots of header only stuff). From a
> quick glance at the docu, it does much more than what's currently
> covered by nvm.dates. But improved date parsing would be nice to have.
> Not sure if it provides the same independence from the system's epoch as
> we currently do.

As I said in my other message, I recall its having specific
portability bugs that hurt us.

Regarding file size, are you sure you're not counting debug
information?  On my (also 64-bit - amd64) machine, the file is 129KB,
but 'size' says it's only got about 7KB of actual code in it.  That's
a n.v.m build; I haven't built your .dates branch but I don't see
anything in there that would bulk it up that much.

Improved date parsing certainly would be nice to have but I think if
we're going to do anything there, it oughta be that we figure out how
to use gnulib's getdate.y, which is the gold standard as far as
user-supplied date parsing.

zw