aboutsummaryrefslogtreecommitdiff
path: root/lib/Makefile.local
diff options
context:
space:
mode:
authorDaniel Kahn Gillmor <dkg@fifthhorseman.net>2017-08-17 19:14:26 -0400
committerDavid Bremner <david@tethera.net>2017-08-23 07:55:12 -0300
commiteb232ee0aba8f031fe4f0cb509682a321d85e06e (patch)
tree54a6bea118976c3f8eb0cc64a83858ccb49abf37 /lib/Makefile.local
parentb10ce6bc23002d48916b1b2f375480e7540e3164 (diff)
reindex: drop notmuch_param_t, use notmuch_indexopts_t instead
There are at least three places in notmuch that can trigger an indexing action: * notmuch new * notmuch insert * notmuch reindex I have plans to add some indexing options (e.g. indexing the cleartext of encrypted parts, external filters, automated property injection) that should properly be available in all places where indexing happens. I also want those indexing options to be exposed by (and constrained by) the libnotmuch C API. This isn't yet an API break because we've never made a release with notmuch_param_t. These indexing options are relevant in the listed places (and in the libnotmuch analogues), but they aren't relevant in the other kinds of functionality that notmuch offers (e.g. dump/restore, tagging, search, show, reply). So i think a generic "param" object isn't well-suited for this case. In particular: * a param object sounds like it could contain parameters for some other (non-indexing) operation. This sounds confusing -- why would i pass non-indexing parameters to a function that only does indexing? * bremner suggests online a generic param object would actually be passed as a list of param objects, argv-style. In this case (at least in the obvious argv implementation), the params might be some sort of generic string. This introduces a problem where the API of the library doesn't grow as new options are added, which means that when code outside the library tries to use a feature, it first has to test for it, and have code to handle it not being available. The indexopts approach proposed here instead makes it clear at compile time and at dynamic link time that there is an explicit dependency on that feature, which allows automated tools to keep track of what's needed and keeps the actual code simple. My proposal adds the notmuch_indexopts_t as an opaque struct, so that we can extend the list of options without causing ABI breakage. The cost of this proposal appears to be that the "boilerplate" API increases a little bit, with a generic constructor and destructor function for the indexopts struct. More patches will follow that make use of this indexopts approach.
Diffstat (limited to 'lib/Makefile.local')
-rw-r--r--lib/Makefile.local1
1 files changed, 1 insertions, 0 deletions
diff --git a/lib/Makefile.local b/lib/Makefile.local
index 0b5c4b08..93b08d15 100644
--- a/lib/Makefile.local
+++ b/lib/Makefile.local
@@ -43,6 +43,7 @@ libnotmuch_c_srcs = \
$(dir)/sha1.c \
$(dir)/built-with.c \
$(dir)/string-map.c \
+ $(dir)/indexopts.c \
$(dir)/tags.c
libnotmuch_cxx_srcs = \