notmuch/Makefile.global, branch 0.37_rc0

build: move {C,CXX}FLAGS to the end of FINAL_{C,CXX}FLAGS

2021-12-31T11:08:06Z

In addition to avoiding problems with user specified include paths picking up an installed version of notmuch.h, this should also enable users to override more options (in particular they could override warning options since the last one takes effect). [1]: id:7851CAB5-4556-4931-A0A2-37003E56C927@ryandesign.com

build: move CPPFLAGS after source directory includes.

2021-12-31T11:07:55Z

In [1] Ryan Schmidt reported a problem on macports [2] with notmuch finding an existing installed version of notmuch.h during the build. This is a partial fix; the user might also specify -I in CFLAGS. [1]: id:7851CAB5-4556-4931-A0A2-37003E56C927@ryandesign.com [2]: The problem does not arise when notmuch.h is installed into a "system" include path that the compiler searches by default.

build: move LDFLAGS after notmuch libraries.

2021-12-31T11:07:32Z

In [1] Ryan Schmidt reported a problem on macports [2] with notmuch finding an existing installed version of libnotmuch during the build when the user specified LDFLAGS including the libnotmuch install directory. This change should prevent that. LDFLAGS also occurs in FINAL_LIBNOTMUCH_LDFLAGS. The only built library linked to that is util/libtnotmuch_util.a, and that passed as explicit (relative) path, and is thus not affected by -L. [1]: id:7851CAB5-4556-4931-A0A2-37003E56C927@ryandesign.com [2]: The problem does not arise when libnotmuch is installed into a "system" library path that the compiler/linker searches by default.

debian: don't tag debian tag at release is made.

2020-12-25T16:28:31Z

This reflects a change in the debian workflow to use dgit, which does the tagging for us. It also leaves room for debian specific fixups.

Rename version to version.txt

2020-10-30T19:14:24Z

Building Notmuch on macOS is known to cause problems because the Notmuch distribution archive contains two files named "version". These names clash with the header as defined in C++20. Therefore, the existing naming will likely become a problem on other platforms as well, once compilers adopt the new standard. Signed-off-by: Ralph Seichter Amended-by: db s/keyword/header/ in commit message.

emacs: Use makefile-gmake-mode in Makefile*s

2020-08-10T00:14:36Z

Use `makefile-gmake-mode' instead of `makefile-mode' because the former also highlights ifdef et al. while the latter does not. "./Makefile.global" and one "Makefile.local" failed to specify any major mode at all but doing so is necessary because Emacs does not automatically figure out that these are Makefiles (of any flavor).

build: upload html docs as part of release process

2020-08-03T23:44:51Z

Use a URL https://notmuchmail.org/doc/latest to leave room for a future more ambitious scheme deploying multiple versions. This also forces the html docs to built as part of the release process. In the future this should be updated to tolerate generating a release without sphinx installed. This needs a new target analogous to build-info and build-man that does nothing if sphinx is not installed.

Makefile.global: drop -std=gnu99. C11 (or later) compiler required

2020-06-27T00:48:56Z

Since October 2018 building notmuch has actually required compiler that knows C11. Also this -std=gnu99 was not used in code compiled by configure, so in theory this could have caused problems... ...but no related reports have been sent, perhaps ever. Both gcc and clang has been shipping compilers supporting C11 (or later) by default for more than four years now. Therefore, just dropping -std=gnu99 (and not checking C11 compatibility for now, for simplicity) is easiest to do, and removes inconsistency between configure and build time compilations.

release: use xz compression

2019-03-27T20:59:40Z

This produces tarballs that are roughly 30% smaller.

build: Rename GPG_FILE to DETACHED_SIG_FILE

2019-03-27T20:54:12Z

This is just a semantic cleanup -- we have multiple files that are OpenPGP signatures. And while we're probably making signatures with GnuPG, they can be verified with any OpenPGP implementation, so "GPG_" is arguably both not specific enough, and overly-specific. Signed-off-by: Daniel Kahn Gillmor