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

[Zack Weinberg]

On Sat, Apr 5, 2008 at 6:41 AM, Markus Schiltknecht <address@hidden> wrote:
>  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...

There's a bit more to it than that; we'd wind up having to modify
their build harnesses anyway for things like ensuring that we only
have one copy of config.guess/config.sub in the tree, idna has pieces
that are GPLv3, autopoint was not cooperating with me when run in a
subdirectory, etc. etc. etc.

I rather *want* to have each subdirectory be just as it was in the
original, but right now I don't think that's going to work.

> 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.

I'll look at that.  I *think* the fix is simple - it appears to just
want one more file - but I was a little scared of the merge process
last night.

>  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.

I definitely think we want to go that way in the long run, but I'd
rather do that as a separate change than this.


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

Ok.

> > 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?

The subdirectory configures must be run from make so we can mess with
their arguments.  There is no way to do that from the top-level
configure script.  Also, this lets me configure the monotone
subdirectory *after* all the libraries are built and installed -- then
it doesn't have to know anything about user selection of bundled
versus system libraries.

zw