From: Tomi Ollila <tomi.ollila@iki.fi>
To: Jameson Graef Rollins <jrollins@finestructure.net>,
	Austin Clements <amdragon@MIT.EDU>
Subject: Re: [PATCH v4 1/7] cli: use typedef to deal with gmime 2.4/2.6
	incompatibility
In-Reply-To: <87wr40s1n4.fsf@servo.finestructure.net>
References: <1337812843-14986-1-git-send-email-jrollins@finestructure.net>
	<1337812843-14986-2-git-send-email-jrollins@finestructure.net>
	<20120525144136.GB11804@mit.edu>
	<87wr40s1n4.fsf@servo.finestructure.net>
User-Agent: Notmuch/0.13+38~g944a859 (http://notmuchmail.org) Emacs/23.1.1
	(x86_64-redhat-linux-gnu)
Date: Fri, 25 May 2012 21:14:49 +0300
Message-ID: <m2zk8wku06.fsf@guru.guru-group.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Notmuch Mail <notmuch@notmuchmail.org>
Precedence: list

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