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
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.
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.
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.
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).
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.
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.
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>
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>
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
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.
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 c10085c77b it
actually needs to be last. To break this conflict, move the variables
definitions into a new Makefile.global.
