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 _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel