notmuch/lib/Makefile.local, branch 0.21

build: extract library versions from notmuch.h

2015-08-10T11:53:55Z

- Make lib/notmuch.h the canonical location for the library versioning information. - Since the release-check should never fail now, remove it to reduce complexity. - Make the version numbers in notmuch.h consistent with the (now deleted) ones in lib/Makefile.local

lib: add public accessor for database from query

2015-08-04T07:11:34Z

This is to make it easier for clients of the library to update to the new error code returning versions of notmuch_query_search_messages

lib, ruby: make use of -Wl,--no-undefined configurable

2015-06-13T15:52:48Z

In particular this is supposed to help build on systems (presumably using a non-gnu ld) where this flag is not available.

lib: make notmuch shared library install_name be full path on Mac OS X

2015-03-06T07:00:18Z

The install_name of libnotmuch.dylib on Mac OS X is what is written into a program that links against it. If it is just the name of the shared library file, as opposed to the full path, the program won't be able to find it when it runs and will abort. Instead, the install_name should be the full path to the shared library (in its final installed location). Why does Notmuch work without this patch when installed via Homebrew? The answer is twofold. One, /usr/local/lib is a special location in which the dynamic linker will look by default to find shared libraries. Homebrew highly recommends installing to /usr/local, and, assuming it has been configured this way, the Notmuch library will end up installed in /usr/local/lib, and the dynamic linker will find it. Two, Homebrew globally corrects all install names in dynamically shared libraries and binaries for each package it installs. So, even if the install names in a package's binaries and libraries are incorrect, Homebrew corrects them automatically, and no one ever knows. Why does Notmuch work without this patch when installed via MacPorts? The answer is that MacPorts applies a patch just like this patch to fix the same problem.

lib: bump SONAME minor version

2015-03-01T07:49:14Z

This indicates upwardly compatible changes, namely adding new symbols. Although we don't formally need to do this until the next release, there is no hard in doing it now, as long as we don't bump the minor version for every addition between now and the release.

lib: bump soname

2014-09-16T18:16:31Z

Adding return values to notmuch_database_close and notmuch_database_destroy may require bumping the soname.

lib: Bump library version from 3.0.0 to 3.1.0

2013-12-07T02:31:19Z

This version of the library introduces LIBNOTMUCH_CHECK_VERSION and the *_VERSION macros. Bumping the version number is also necessary to make the comment on LIBNOTMUCH_CHECK_VERSION no longer a lie.

lib: Make VERSION macros agree with soname version

2013-12-07T02:31:04Z

We have two distinct "library version" numbers: the soname version and the version macros. We need both for different reasons: the version macros enable easy compile-time version detection (and conditional compilation), while the soname version enables runtime version detection (which includes the version checking done by things like the Python bindings). However, currently, these two version numbers are different, which is unnecessary and can lead to confusion (especially in things like Debian, which include the soname version in the package name). This patch makes them the same by bumping the version macros up to agree with the soname version. (We should probably keep the version number in just one place so they can't get out of sync, but that can be done in another patch.)

lib/Makefile.local: depend on libs we are linking with

2013-01-22T12:59:33Z

lib: add date range query support

2012-10-31T19:55:32Z

Add a custom value range processor to enable date and time searches of the form date:since..until, where "since" and "until" are expressions understood by the previously added date/time parser, to restrict the results to messages within a particular time range (based on the Date: header). If "since" or "until" describes date/time at an accuracy of days or less, the values are rounded according to the accuracy, towards past for "since" and towards future for "until". For example, date:november..yesterday would match from the beginning of November until the end of yesterday. Expressions such as date:today..today means since the beginning of today until the end of today. Open-ended ranges are supported (since Xapian 1.2.1), i.e. you can specify date:..until or date:since.. to not limit the start or end date, respectively. CAVEATS: Xapian does not support spaces in range expressions. You can replace the spaces with '_', or (in most cases) '-', or (in some cases) leave the spaces out altogether. Entering date:expr without ".." (for example date:yesterday) will not work as you might expect. You can achieve the expected result by duplicating the expr both sides of ".." (for example date:yesterday..yesterday). Open-ended ranges won't work with pre-1.2.1 Xapian, but they don't produce an error either. Signed-off-by: Jani Nikula