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

[Markus Schiltknecht]

Hi,

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
> configure.ac'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?

Regards

Markus