Hi David!

Thanks for getting back to me about this.
Currently configure (with some patches) says:

Checking for Xapian development files... Yes (1.2.17).
Checking for Xapian compaction support... Yes.
Checking for GMime development files... Yes (gmime-2.4 ).
Checking for Glib development files (>= 2.22)... Yes.
Checking for zlib (>= 1.2.5.2)... Yes.
Checking for talloc development files... Yes.
Checking for valgrind development files... No (but that's fine).
Checking for bash-completion (>= 1.90)... No (will not install bash completion).
Checking if emacs is available... emacs: not found
No (so will not byte-compile emacs code)
Checking if sphinx is available and supports nroff output... python: not found
No (falling back to rst2man).
Checking if rst2man is available... Yes.
Checking which platform we are on... Unknown.

*** Warning: Unknown platform. Notmuch might or might not build correctly.

Checking byte order... 1234
Checking for canonicalize_file_name... No (will use our own instead).
Checking for getline... Yes.
Checking for strcasestr... Yes.
Checking for strsep... Yes.
Checking for timegm... Yes.
Checking for dirent.d_type... Yes.
Checking for standard version of getpwuid_r... Yes.
Checking for standard version of asctime_r... Yes.
Checking for rpath support... Yes.
Checking for -Wl,--as-needed... Yes.
Checking for available C++ compiler warning flags... 
        -Wall -Wextra -Wwrite-strings
Checking for available C compiler warning flags... 
        -Wall -Wextra -Wwrite-strings -Wmissing-declarations

so this particular issue seems to be fixed, right?

I had some other issues with 0.18 though.

1. pkgsrc's copy of rst2man is called "rst2man.py". The configure test
for this fails, of course, and there is another place where rst2man is
called directly. I've changed that to rst2man.py locally, but it'd be
good if configure could test for both names, set a variable to the one
found, and use the variable in the other place.

2. doc/Makefile.local has "python" hardcoded. pkgsrc supports multiple
python versions at the same time, with the disadvantage that there is
no "python" executable, only "python2.6", "python2.7", "python3.3"
etc. I've passed in the proper executable name as PYTHONBIN and used
it in the Makefile.

3. installation of notmuch-version.el fails, because the install rule
has no dependency on the generated file notmuch-version.el. I've added
such a dependency.

The patches I used to make notmuch build are attached, but I can of
course test other patches if you prefer different solutions. I haven't
really run this version of notmuch yet.

Cheers,
 Thomas