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

[David Bremner <david@tethera.net>]

Tomi Ollila <tomi.ollila@iki.fi> writes:

> On Sat, Mar 26 2016, David Bremner <david@tethera.net> wrote:
>
>
> notmuch_bool_t
> notmuch_options_get (const char *name) {
>     if (STRNCMP_LITERAL (name, "compact") == 0) {
> 	return HAVE_XAPIAN_COMPACT;
> 	// or return HAVE_XAPIAN_COMPACT? TRUE: FALSE;
> 	// or return !! HAVE_XAPIAN_COMPACT;
>     } else if (STRNCMP_LITERAL (name, "field_processor") == 0) {
> 	return HAVE_XAPIAN_FIELD_PROCESSOR;
>     } else {
> 	return FALSE;
>     }
> }

I have no real objection to this. It's a bit slower than matching
against an enum, but I don't see this being in any performance critical
paths.

>
> ... note: if this notmuch_options_present () function prevails, fix
> the later #if check ;D
>
> ... and
>
> void
> _notmuch_config_list_options () {
>     printf("options.compact=%s\n",
> 	   HAVE_XAPIAN_COMPACT ? "true" : "false");
>     printf("options.field_processor=%s\n",
> 	   HAVE_XAPIAN_FIELD_PROCESSOR ? "true" : "false");
> }
>

This I'm not so sure about. There's a subtle distinction between what is
supported in the CLI and what is supported in the lib, and we really
want the latter. So I do think _some_ library routine is needed.

> (kept the 'options' naming and prefix in this context)

As far as the naming goes, I agree options is a bit weird. We could call
these things library features and the existing ones database features,
since the the latter are not really exposed to users.  Other possible
words are

      trait
      attribute
      property