Hi,
On IRC we recently had a discussion about using boost::date_time instead
of rolling our own in dates.{cc,hh} - as I've been doing in nvm.dates.
I've been under the impression, that we do not want to rely on boost
libraries. But in nvm.stripped I'm working on linking monotone against
other libraries as well, so it seems we need to revisit the question of
how to work with 3rd party modules in general.
There are three major options, all of which we've already used:
* Dynamic linking to external libraries. We've always linked against
libz, for example. Pros: low maintenance cost for us, enjoy newer
versions by replacing the lib - Cons: dependencies on other libs, mtn
needs to (dynamically) cope with various versions of the lib.
* Source inclusion: we've done that for botan, sqlite, lua, pcre and
others. Pros: need to support only one version, independence of upstream
(i.e. netxx is dead) - Cons: high maintenance cost for us, packagers
don't like it.
* Avoid the library: we are currently doing that with boost, for
example. Pros: no dependency, no license issues, code exactly what we
need - Cons: hight maintenance and development costs for us.
I think pros and cons are pretty clear, sure you can still add some
general ones here and there. Just wanting to make sure we speak about
the same things.
Now, let's get to the single libraries we use:
* libz: dynamic linking hasn't posed any problems and the library seems
to be available on pretty much any system.
* 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.
* 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.
* 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.
* 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.
* boost: we've done quite a lot of work to get rid of boost and
replaced it with our own code. It began with boost::fs (see [1]) and
continued with test, regex, date_time and probably others. Now we only
rely on some boost header files, but we don't "source include" these
ATM. Reading the ML-archive, there are several complaints about
difficulties building boost, it's bjam based build harness is a bit
uncommon. Botan also provides it's own (perl based) configure script.
And autoconf is far from being everybody's friend. Boost is old enough
to be shipped with most major distributions.
The reason for removing boost::regexp were, that it's bloated. pcre is
much smaller. I'm unsure about boost::test and boost::date_time.
If we really decide to not want any boost library, I'd like to
a) be clearer about the reasons and
b) "source include" the required boost header files, so as to really be
independent of boost.
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.
I've dropped boost::graph from nvm.cvsimport-branch-reconstruction and
coded my own graph stuff (i.e. a dijkstra search algo) for better
performance and flexibility (different in-memory representation from
boost's).
In the archive I've read that boost::program_options didn't do what we
want. Looking at the boots documentation, I also see boost::asio - could
that perhaps be a better replacement for the (unmaintained) netxx?
Anybody used boost::asio before?
Thoughts? Comments?
Regards
Markus Wanner
[1]: Nathaniel: boost::fs is slow:
http://article.gmane.org/gmane.comp.version-control.monotone.devel/4262
_______________________________________________
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
