Re: [Patch v2 04/13] lib/cli: add library API / CLI for compile time options

diff --git a/92/018fd63ea24b9a3d8a34a9125a0a31910bce5b b/92/018fd63ea24b9a3d8a34a9125a0a31910bce5b
new file mode 100644 (file)
index 0000000..179156d
--- /dev/null
+++ b/92/018fd63ea24b9a3d8a34a9125a0a31910bce5b
@@ -0,0 +1,107 @@
+Return-Path: <david@tethera.net>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by arlo.cworth.org (Postfix) with ESMTP id B03706DE034D\r
+ for <notmuch@notmuchmail.org>; Sat, 30 Apr 2016 04:54:05 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at cworth.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.015\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.015 tagged_above=-999 required=5\r
+ tests=[AWL=-0.004, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01]\r
+ autolearn=disabled\r
+Received: from arlo.cworth.org ([127.0.0.1])\r
+ by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id l4n0nQWwS4KZ for <notmuch@notmuchmail.org>;\r
+ Sat, 30 Apr 2016 04:53:57 -0700 (PDT)\r
+Received: from fethera.tethera.net (fethera.tethera.net [198.245.60.197])\r
+ by arlo.cworth.org (Postfix) with ESMTPS id C5F6C6DE0022\r
+ for <notmuch@notmuchmail.org>; Sat, 30 Apr 2016 04:53:57 -0700 (PDT)\r
+Received: from remotemail by fethera.tethera.net with local (Exim 4.84)\r
+ (envelope-from <david@tethera.net>)\r
+ id 1awTT4-0005Jc-3b; Sat, 30 Apr 2016 07:53:50 -0400\r
+Received: (nullmailer pid 5396 invoked by uid 1000);\r
+ Sat, 30 Apr 2016 11:53:52 -0000\r
+From: David Bremner <david@tethera.net>\r
+To: Tomi Ollila <tomi.ollila@iki.fi>, notmuch@notmuchmail.org\r
+Subject: Re: [Patch v2 04/13] lib/cli: add library API / CLI for compile time\r
+ options\r
+In-Reply-To: <m27ffjvt9j.fsf@guru.guru-group.fi>\r
+References: <1459015043-8460-1-git-send-email-david@tethera.net>\r
+ <1459015043-8460-5-git-send-email-david@tethera.net>\r
+ <m27ffjvt9j.fsf@guru.guru-group.fi>\r
+User-Agent: Notmuch/0.21+99~gd93d377 (http://notmuchmail.org) Emacs/24.5.1\r
+ (x86_64-pc-linux-gnu)\r
+Reply-To: me@example.com\r
+Date: Sat, 30 Apr 2016 08:53:52 -0300\r
+Message-ID: <87inyz8g8f.fsf@zancas.localnet>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.20\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <https://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: <https://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Sat, 30 Apr 2016 11:54:05 -0000\r
+\r
+Tomi Ollila <tomi.ollila@iki.fi> writes:\r
+\r
+> On Sat, Mar 26 2016, David Bremner <david@tethera.net> wrote:\r
+>\r
+>\r
+> notmuch_bool_t\r
+> notmuch_options_get (const char *name) {\r
+>     if (STRNCMP_LITERAL (name, "compact") == 0) {\r
+>      return HAVE_XAPIAN_COMPACT;\r
+>      // or return HAVE_XAPIAN_COMPACT? TRUE: FALSE;\r
+>      // or return !! HAVE_XAPIAN_COMPACT;\r
+>     } else if (STRNCMP_LITERAL (name, "field_processor") == 0) {\r
+>      return HAVE_XAPIAN_FIELD_PROCESSOR;\r
+>     } else {\r
+>      return FALSE;\r
+>     }\r
+> }\r
+\r
+I have no real objection to this. It's a bit slower than matching\r
+against an enum, but I don't see this being in any performance critical\r
+paths.\r
+\r
+>\r
+> ... note: if this notmuch_options_present () function prevails, fix\r
+> the later #if check ;D\r
+>\r
+> ... and\r
+>\r
+> void\r
+> _notmuch_config_list_options () {\r
+>     printf("options.compact=%s\n",\r
+>         HAVE_XAPIAN_COMPACT ? "true" : "false");\r
+>     printf("options.field_processor=%s\n",\r
+>         HAVE_XAPIAN_FIELD_PROCESSOR ? "true" : "false");\r
+> }\r
+>\r
+\r
+This I'm not so sure about. There's a subtle distinction between what is\r
+supported in the CLI and what is supported in the lib, and we really\r
+want the latter. So I do think _some_ library routine is needed.\r
+\r
+> (kept the 'options' naming and prefix in this context)\r
+\r
+As far as the naming goes, I agree options is a bit weird. We could call\r
+these things library features and the existing ones database features,\r
+since the the latter are not really exposed to users.  Other possible\r
+words are\r
+\r
+      trait\r
+      attribute\r
+      property\r
+      \r
+      \r