On Fri, May 25 2012, Jameson Graef Rollins <jrollins@finestructure.net> wrote: > On Fri, May 25 2012, Austin Clements <amdragon@MIT.EDU> wrote: >>> diff --git a/notmuch-client.h b/notmuch-client.h >>> index 19b7f01..337409f 100644 >>> --- a/notmuch-client.h >>> +++ b/notmuch-client.h >>> @@ -36,6 +36,8 @@ >>> * these to check the version number. */ >>> #ifdef GMIME_MAJOR_VERSION >>> #define GMIME_ATLEAST_26 >>> +#else >>> +typedef GMimeCipherContext GMimeCryptoContext; >> >> I like the typedef idea, but I don't think we should overload >> GMimeCryptoContext like this. If someone is reading through the GMime >> 2.4 code and sees this, they're going to assume that it's a GMime >> structure, go looking for it, find that it's only in 2.6 and be >> baffled. Instead, how about providing a typedef to abstract *both* >> cases? Something like >> >> #ifdef GMIME_MAJOR_VERSION >> #define GMIME_ATLEAST_26 >> typedef notmuch_crypto_context_t GMimeCipherContext; >> #else >> typedef notmuch_crypto_context_t GMimeCryptoContext; >> #endif > > Hey, Austin. I briefly thought about this, but it seemed kind of heavy > handed given that I hope these ifdefs will go away in the > not-too-distant future. Do we really have a lot of gmime 2.4 readers > that would not have access to gmime 2.6 documentation? I'm pretty sure > that I would personally end up looking at documentation for both > versions. > > But anyway, if this really is a concern, I guess it's not *that* much > effort to support a new typedef indefinitely to alleviate any potential > confusion. > > Any other opinions? I like Austin's suggestion; as long as gmime 2.4 is supported it is clearer that the type name is not just a little different -- someone browsing gmime 2.4 code may experience some WTF:s (or was it FTW, cannot remember ;) when they try to locate GMimeCipherContext there... and, in if in some day gmime 2.4 support is dropped, M-x tags-query-replace can be used to drop the notmuch_crypto_context_t type. I personally am using gmime 2.4 as it has much less other requirements (i.e. ./configure --prefix=... && make install does it -- gmime 2.6 requires some other "nondefault" libraries also) and I don't plan to update that (and not the least reason is that I keep testing 2.4 compatibility all the time when new commits appear to my git tree) > jamie. Tomi