On Sat, Apr 5, 2008 at 6:41 AM, Markus Schiltknecht <[EMAIL PROTECTED]> 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 _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel