From d2f1e675bafeb964b87e50029cfe823e441ffadf Mon Sep 17 00:00:00 2001 From: Tomi Ollila Date: Fri, 25 May 2012 21:14:49 +0300 Subject: [PATCH] Re: [PATCH v4 1/7] cli: use typedef to deal with gmime 2.4/2.6 incompatibility --- d5/0cdf90559faa721cdbc63c57947f8806706292 | 113 ++++++++++++++++++++++ 1 file changed, 113 insertions(+) create mode 100644 d5/0cdf90559faa721cdbc63c57947f8806706292 diff --git a/d5/0cdf90559faa721cdbc63c57947f8806706292 b/d5/0cdf90559faa721cdbc63c57947f8806706292 new file mode 100644 index 000000000..aa584d3b4 --- /dev/null +++ b/d5/0cdf90559faa721cdbc63c57947f8806706292 @@ -0,0 +1,113 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by olra.theworths.org (Postfix) with ESMTP id CAFE3431FBC + for ; Fri, 25 May 2012 11:14:39 -0700 (PDT) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: 0 +X-Spam-Level: +X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] + autolearn=disabled +Received: from olra.theworths.org ([127.0.0.1]) + by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id x4FxynFFTFVq for ; + Fri, 25 May 2012 11:14:38 -0700 (PDT) +Received: from guru.guru-group.fi (guru.guru-group.fi [46.183.73.34]) + by olra.theworths.org (Postfix) with ESMTP id 84D49431FB6 + for ; Fri, 25 May 2012 11:14:38 -0700 (PDT) +Received: by guru.guru-group.fi (Postfix, from userid 501) + id 23D04100641; Fri, 25 May 2012 21:14:49 +0300 (EEST) +From: Tomi Ollila +To: Jameson Graef Rollins , + Austin Clements +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) +X-Face: HhBM'cA~ +MIME-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Cc: Notmuch Mail +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.13 +Precedence: list +List-Id: "Use and development of the notmuch mail system." + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +X-List-Received-Date: Fri, 25 May 2012 18:14:39 -0000 + +On Fri, May 25 2012, Jameson Graef Rollins wrote: + +> On Fri, May 25 2012, Austin Clements 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 -- 2.26.2