Re: [Botan-devel] [Monotone-devel] library build

[Zbigniew Zagórski]

2008/10/2 Markus Wanner <address@hidden>
> Zbigniew Zagórski wrote:
> > BTW, 1.7.15 has minor change of API that makes some things ugly in
> > monotone if we want to use system provided libraries.
>
> AFAIU the 1.7.x branch of botan is a development branch so we have to
> deal with API changes in monotone.
>
> > In lookup.h there are few get_cipher functions than in 1.7.14 and
> > earlier versions where independent of Library_State and in 1.7.15 they
> > require LibraryState& as first parameter. ***

My mistake, Library_State dependency in get_cipher was introduced in 1.7.14
(1.7.15 is trunk in this discussion)

> I'm not sure which branch of monotone you are talking about.
nvm.stripped

> For
> nvm.stripped, which I've started yesterday, that's already solved.
> Testing with the most recent botan revision (as of yesterday) worked
> just fine - and worked down to 1.7.8, as mentioned on the mailing list.
> For monotone head this is not an issue since that's at botan 1.7.12
> (since I've propagated from nvm.botan yesterday).

When I've read this i thougth that i've made something stupid, why it haven't
compiled on my system (?). Yes there are the ifdefs i haven't seen
them yesterday
when I was building.

#if BOTAN_VERSION_PATCH >= 15
        Pipe arc4_decryptor(get_cipher(Botan::global_state(), "ARC4",
                                       arc4_key, Botan::DECRYPTION));
#else
        // botan before 1.7.15 didn't have a global state object
        Pipe arc4_decryptor(get_cipher("ARC4", arc4_key, Botan::DECRYPTION));
#endif

Here 15 should be changed to 14 (will do in minutes).

Sorry for noise. All this was caused by botan/build.h not being
installed by all invocations
of botans  "make install".

I think we earned something from this discussion 1.7.15 now doesn't have
Library_State in get_cipher and it's only in 1.7.14.
More, we should rethink if botan should be system library in there is risk that
someone will have only 1.6.Y or some old and incompatible 1.7.X on his system.
...

> > I don't question your design decisions but LibraryState& is currently
> > a singleton obtained via (AFAIR) Botan::get_default() so i don't see
> > any reason for removing Botan::get_cipher overloads without
> > LibraryState& (correct me if I'm wrong).
> >
> > Old overloads can be marked as deprecated but it is wise to leave them
> > for a while because current code base uses them.
>
> That does not really apply for development branches, where the API is
> known to change.

Well I have rather conservative view of how binary API should evolve:
interfaces
should in general only grow and deprecated elements should be removed
with some latency and deprecation warnings in documentation. I admit its
one of few advantages of otherwise awfull WinAPI.

But that's an a little off topic for this discussion ... so let's
leave this for some cold winter evening.

--
Zbigniew Zagórski
/ software developer / geek / happy daddy /