Re: [PATCH v4 1/7] cli: use typedef to deal with gmime 2.4/2.6 incompatibility

diff --git a/d5/0cdf90559faa721cdbc63c57947f8806706292 b/d5/0cdf90559faa721cdbc63c57947f8806706292
new file mode 100644 (file)
index 0000000..aa584d3
--- /dev/null
+++ b/d5/0cdf90559faa721cdbc63c57947f8806706292
@@ -0,0 +1,113 @@
+Return-Path: <tomi.ollila@iki.fi>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+       by olra.theworths.org (Postfix) with ESMTP id CAFE3431FBC\r
+       for <notmuch@notmuchmail.org>; Fri, 25 May 2012 11:14:39 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 0\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]\r
+       autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+       by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+       with ESMTP id x4FxynFFTFVq for <notmuch@notmuchmail.org>;\r
+       Fri, 25 May 2012 11:14:38 -0700 (PDT)\r
+Received: from guru.guru-group.fi (guru.guru-group.fi [46.183.73.34])\r
+       by olra.theworths.org (Postfix) with ESMTP id 84D49431FB6\r
+       for <notmuch@notmuchmail.org>; Fri, 25 May 2012 11:14:38 -0700 (PDT)\r
+Received: by guru.guru-group.fi (Postfix, from userid 501)\r
+       id 23D04100641; Fri, 25 May 2012 21:14:49 +0300 (EEST)\r
+From: Tomi Ollila <tomi.ollila@iki.fi>\r
+To: Jameson Graef Rollins <jrollins@finestructure.net>,\r
+       Austin Clements <amdragon@MIT.EDU>\r
+Subject: Re: [PATCH v4 1/7] cli: use typedef to deal with gmime 2.4/2.6\r
+       incompatibility\r
+In-Reply-To: <87wr40s1n4.fsf@servo.finestructure.net>\r
+References: <1337812843-14986-1-git-send-email-jrollins@finestructure.net>\r
+       <1337812843-14986-2-git-send-email-jrollins@finestructure.net>\r
+       <20120525144136.GB11804@mit.edu>\r
+       <87wr40s1n4.fsf@servo.finestructure.net>\r
+User-Agent: Notmuch/0.13+38~g944a859 (http://notmuchmail.org) Emacs/23.1.1\r
+       (x86_64-redhat-linux-gnu)\r
+X-Face: HhBM'cA~<r"^Xv\KRN0P{vn'Y"Kd;zg_y3S[4)KSN~s?O\"QPoL\r
+       $[Xv_BD:i/F$WiEWax}R(MPS`^UaptOGD`*/=@\1lKoVa9tnrg0TW?"r7aRtgk[F\r
+       !)g;OY^,BjTbr)Np:%c_o'jj,Z\r
+Date: Fri, 25 May 2012 21:14:49 +0300\r
+Message-ID: <m2zk8wku06.fsf@guru.guru-group.fi>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=us-ascii\r
+Cc: Notmuch Mail <notmuch@notmuchmail.org>\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+       <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Fri, 25 May 2012 18:14:39 -0000\r
+\r
+On Fri, May 25 2012, Jameson Graef Rollins <jrollins@finestructure.net> wrote:\r
+\r
+> On Fri, May 25 2012, Austin Clements <amdragon@MIT.EDU> wrote:\r
+>>> diff --git a/notmuch-client.h b/notmuch-client.h\r
+>>> index 19b7f01..337409f 100644\r
+>>> --- a/notmuch-client.h\r
+>>> +++ b/notmuch-client.h\r
+>>> @@ -36,6 +36,8 @@\r
+>>>   * these to check the version number. */\r
+>>>  #ifdef GMIME_MAJOR_VERSION\r
+>>>  #define GMIME_ATLEAST_26\r
+>>> +#else\r
+>>> +typedef GMimeCipherContext GMimeCryptoContext;\r
+>>\r
+>> I like the typedef idea, but I don't think we should overload\r
+>> GMimeCryptoContext like this.  If someone is reading through the GMime\r
+>> 2.4 code and sees this, they're going to assume that it's a GMime\r
+>> structure, go looking for it, find that it's only in 2.6 and be\r
+>> baffled.  Instead, how about providing a typedef to abstract *both*\r
+>> cases?  Something like\r
+>>\r
+>> #ifdef GMIME_MAJOR_VERSION\r
+>> #define GMIME_ATLEAST_26\r
+>> typedef notmuch_crypto_context_t GMimeCipherContext;\r
+>> #else\r
+>> typedef notmuch_crypto_context_t GMimeCryptoContext;\r
+>> #endif\r
+>\r
+> Hey, Austin.  I briefly thought about this, but it seemed kind of heavy\r
+> handed given that I hope these ifdefs will go away in the\r
+> not-too-distant future.  Do we really have a lot of gmime 2.4 readers\r
+> that would not have access to gmime 2.6 documentation?  I'm pretty sure\r
+> that I would personally end up looking at documentation for both\r
+> versions.\r
+>\r
+> But anyway, if this really is a concern, I guess it's not *that* much\r
+> effort to support a new typedef indefinitely to alleviate any potential\r
+> confusion.\r
+>\r
+> Any other opinions?\r
+\r
+I like Austin's suggestion; as long as gmime 2.4 is supported it is clearer\r
+that the type name is not just a little different -- someone browsing gmime\r
+2.4 code may experience some WTF:s (or was it FTW, cannot remember ;) when\r
+they try to locate GMimeCipherContext there...\r
+\r
+and, in if in some day gmime 2.4 support is dropped, M-x tags-query-replace\r
+can be used to drop the notmuch_crypto_context_t type.\r
+\r
+I personally am using gmime 2.4 as it has much less other requirements\r
+(i.e. ./configure --prefix=... && make install does it -- gmime 2.6\r
+requires some other "nondefault" libraries also) and I don't plan to update\r
+that (and not the least reason is that I keep testing 2.4 compatibility\r
+all the time when new commits appear to my git tree)\r
+\r
+> jamie.\r
+\r
+Tomi\r