[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] library-build progress report and request for help

From: Markus Schiltknecht
Subject: Re: [Monotone-devel] library-build progress report and request for help with botan
Date: Sat, 05 Apr 2008 12:41:23 +0200
User-agent: Mozilla-Thunderbird (X11/20080110)


Zack Weinberg wrote:
Right now what works is building idna, lua, netxx, and pcre.  My
original intent was to have these be verbatim upstream tarballs but
that proved impractical, I've pretty much written my own Makefiles and's for all of them.  [Only idna and pcre have upstream
build harnesses that are any use, and they both have tons of unrelated
junk that we don't want cluttering up the repository.]

Well, if cluttering up the repository is the only counter argument, I'd say better use their build harnesses, because maintenance and upgrading becomes much simpler. Otherwise, we will have to maintain our own build harness for that, which is about as bad as it is today.

But it sounds like you hit other problems as well. I'm just pointing out the maintenance aspect again...

botan builds but does not install, because we are using the upstream
build harness for that, and it wants files that were left out of the
original import.  I would appreciate help from people who've done
upstream botan imports on that front.

I was trying to keep the current, stripped botan variant, so as to keep changes to a minimum. That one gets propagated from ... uhm... au...matthew.something.somewhere... see botan/README.monotone, I've updated comments in there.

But maybe it's not worth maintaining that upgrading strategy. Instead, let's just replace it with the original tarball.

It's the same 'cluttering' vs 'simple maintenance' decision: we currently have a sleek and stripped botan for monotone. I didn't dare giving that up for simpler maintenance, yet. But in the long run, we *should* replace it with the tarball, I think. Cluttering the repository is much less expensive for us, than having to clean up our own test harness for every botan release.

sqlite doesn't build - I just
haven't gotten to that one yet.  I'd like to know, though, whether we
want to move to sqlite 3.5.7 separately or as part of this project
(looking at the big picture, my inclination is to say "separately",
but doing it as part of this project might make this project a wee
easier - you'll note that I updated the idna directory, where the
tradeoff is clearer).

I'd certainly vote for decoupling these changes, because it might actually be *less* work in the end, due to simpler testing and debugging.

Don't even try building the monotone subdirectory yet.

People wanting to experiment may find the toplevel targets "make
<dir>/Makefile" and "make libinst/<dir>-stamp" of use.

This sounds like you've displaced autoconf somewhat. I've thought it would be clearer if ./configure would also configure the sub directories. What were the reasons for doing that from make?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]