Re: [Monotone-devel] could we get away with requiring perl during the build, for botan's sake?

[Zack Weinberg]

On 10/16/07, Markus Schiltknecht <address@hidden> wrote:
>
> Ehm.. configure.pl has been in botan since its very beginning. We are
> not including it in monotone, instead we use pre-configured sources.
> Have a look at botan/README.botan-monotone in n.v.m, about how botan is
> included in monotone.

I didn't realize it had been present since the beginning, but I did
realize we used pre-configured sources.  The file you cite doesn't say
anything about the configuration itself, though.

> I've already gone through the steps necessary and upgraded monotone to
> botan 1.7.2, at least in n.v.m.botan. I'm just running 'make check', but
> AFAICS it's ready for propagation to n.v.m. Any objections?

I was going to say that it might be better to go with the 1.6 branch,
but since I see you've put 1.7.2 in already, no point taking it back
out again.

> It's important to note that we are potentially loosing CPU specific
> optimizations. Because due to not running configure.pl, we build a
> generic variant (with a static build.h). AFAICT botan doesn't provide
> lots of optimized assembler code, yet. So that might not be much of an
> issue, yet.

It's the CPU-specific optimizations that I was hoping to pick up on
with configure.pl.  I see downthread that they don't make much
difference for our usage pattern right now, but nonetheless, botan's
sha1function is consistently in the top ten on profiles, often more
than 10% of runtime; it would be nice to be *able* to take advantage
of good hand-tuned assembly versions.   (Wasn't someone going to
sanitize the openssh sha1 for use in botan??)

> However, once again it occurs to me, that it's silly stating that we
> don't have any external dependencies and instead drag in complete source
> codes of other projects. Using dynamic libraries certainly has its own
> set of problems, but IMO it's the more standard way to go.

With my Debian package manintaner hat on I definitely want to take us
in that direction; but there are real problems we've had in the past
with that (I understand mostly with sqlite?) so caution is wisest.

zw