build: move {C,CXX}FLAGS to the end of FINAL_{C,CXX}FLAGS 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. 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. 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. 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 Building Notmuch on macOS is known to cause problems because the Notmuch distribution archive contains two files named "version". These names clash with the <version> 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 <github@seichter.de> Amended-by: db s/keyword/header/ in commit message.
emacs: Use makefile-gmake-mode in Makefile*s 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 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 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 This produces tarballs that are roughly 30% smaller.
build: Rename GPG_FILE to DETACHED_SIG_FILE 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 <dkg@fifthhorseman.net>
build: distribute signed sha256sums Distribute clearsigned sha256sum file in addition to the detached signature. Verifies that use the sha256sum ensure that the thing signed includes the name of the tarball. This defends the verifier by default against a freeze, rollback, or project substitution attack. A verifier can use something like the following (as expressed in bash): set -o pipefail wget https://notmuchmail.org/releases/notmuch-$VERSION.tar.gz{,.sha256.asc} gpgv --keyring ./notmuch-signers.pgp --output - notmuch-$VERSION.tar.gz.sha256.asc | sha256sum -c - See id:87r2b8w956.fsf@fifthhorseman.net and other messages in that thread for discussion. Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
build: sign tarball instead of sha256sum Adam Majer pointed out in [1] the way were signing releases was unusual. Neither Carl nor I could think of a good reason for explicitely signing the checksum (internally of course that's what GPG is going anyway). [1] mid:b3fd556d-c346-7af9-a7a2-13b0f3235071@suse.de
rename libutil.a to libnotmuch_util.a Apparently some systems (MacOS?) have a system library called libutil and the name conflict causes problems. Since this library is quite notmuch specific, rename it to something less generic.
build: use sha256sum instead of sha1sum to sign releases
build/emacs: add target to create elpa package This package can be created without emacs, but will only be usable in versions of emacs supporting package.el
build: Move variable definitions to Makefile.global I noticed when trying to use VERSION (and derived variables) in a subdirectory that the top level Makefile.local needed to be included first. But according to c10085c77b407d9ea704f8b4f9e0a805f63e72cb it actually needs to be last. To break this conflict, move the variables definitions into a new Makefile.global.