The extra flexibility of having both HAVE_EMACS (for yes, there is an
emacs we can use) and WITH_EMACS (the user wants emacs support) lead
to confusion and bugs. We now just force WITH_EMACS to 0 if no
suitable emacs is detected.
When using a promiscuous linker, _check_session_keys was working fine.
But some OSes (including some versions of Ubuntu) have set their
linker to always link in "--as-needed" mode, which means that the
order of the objects linked is relevant. If a library is loaded
before it is needed, that library will no longer be linked in the
final outcome. _check_session_keys.c was failing on those systems.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
We never want ./configure to try to do something with an unassigned
variable. So, make the directory $TEMP_GPG at the start of the
testing of session-key handling, and clean it up afterwards as long as
the directory exists.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
There are a few changes bundled here:
* say "No." explicitly if there's a failure.
* try to avoid implying that gpgme-config is necessary to build
notmuch itself (it's not, though it may be useful if you need to
rebuild gmime).
* leave _check_session_keys and _check_session_keys.c around if
./configure fails, so that the user can play with it more easily
for debugging.
* let error messages show when _check_session_keys.c is built.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Amended by DB: use command -v instead of which.
GMime 3.0 and higher can extract session keys, but it will *not*
extract session keys if it was built with --disable-crypto, or if it
was built against GPGME version < 1.8.0.
Notmuch currently expects to be able to extract session keys, and
tests will fail if it is not possible, so we ensure that this is the
case during ./configure time.
Part of this feels awkward because notmuch doesn't directly depend on
gpg at all. Rather, it depends on GMime, and the current
implementation of GMime depends on GPGME for its crypto, and GPGME in
turn depends on gpg.
So the use of gpg in ./configure isn't actually introducing a new
dependency, though if a future version of GMime were ever to move away
from GnuPG, we might need to reconsider.
Note that this changeset depends on
id:20190506174327.13457-1-dkg@fifthhorseman.net , which supplies the
rfc822 message test/corpora/crypto/basic-encrypted.eml used in it.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
GMime 3.0 is over 2 years old now, and 2.6 has been deprecated in
notmuch for about 1.5 years.
Comments and documentation no longer need to refer to GMime 2.6, so
clean them all up.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
If e.g. /lib is a link to /usr/lib, then the latter may not show up in
the way we expect in the output of ldconfig. 'test foo -ef bar' checks
if foo and bar have the same device and inode numbers. Since (at least
in bash, dash, ksh, and zsh) the shell dereferences symlinks before
applying the test, this includes both the case where file1 is equal to
file2 and the case where one is a symlink to the other.
This way, one can build for a different Ruby than $PATH/ruby
(e. g. different versions, or Ruby in other paths).
Signed-off-by: Thomas Schneider <qsx@chaotikum.eu>
Correct URLs that have crept into the notmuch codebase with http://
when https:// is possible.
As part of this conversion, this changeset also indicates the current
preferred upstream URLs for both gmime and sup. the new URLs are
https-enabled, the old ones are not.
This also fixes T310-emacs.sh, thanks to Bremner for catching it.
When i'm trying to understand a message signature, i care that i know
who it came from (the "validity" of the identity associated with the
key), *not* whether i'm willing to accept the keyholder's other
identity assertions (the "trust" associated with the certificate).
We've been reporting User ID information based on the "trust"
associated with the certificate, because GMime didn't clearly expose
the validity of the User IDs.
This change relies on fixes made in GMime 3.0.3 and later which
include https://github.com/jstedfast/gmime/pull/18.
"notmuch help" doesn't mention "notmuch-emacs-mua" even though we
support it through the try_external_command() mechanism.
In addition, "notmuch help emacs-mua" doesn't work, even though we
ship the appropriate manpage.
This changeset fixes both of these problems.
python2 is going to be deprecated, and python3-sphinx is available all
the way back to oldoldstable. let's use the more modern version.
To make this work and still ship the manpages, tell ./configure to
prefer python3 over python, if it exists.
This flag should make it easier to write the code for session-key
handling.
Note that this only works for GMime 2.6.21 and later (the session key
interface wasn't available before then). It should be fine to build
the rest of notmuch if this functionality isn't available.
Note that this also adds the "session_key" built_with() aspect to
libnotmuch.
The advantage of having a target as opposed to running cppcheck by
hand
- reuse list of source files
- output errors in a format parsable, e.g. by emacs
- returns exit code 1 on any error, for possibly use in other
targets.
For the moment, leave this as an optional target. If desired, it can
be added to e.g. the release targets in the same way as the test
target.
Using two levels of directory for the stamps is arguably
overengineering, but it doesn't really cost anything, and leaves open
the possibility of putting other kinds of stamp files there.
This only checks "new" source files (w.r.t. their last check). A future target
(cppcheck-all ?) could blow away the stamp files first.
When configure could not get past initial compiler sanity check
the user was left with no explanation why this happened (usually
the reason is that compilers are not installed).
By printing the executed command line and re-executing it without
output redirection user gets better information how to proceed
(or ask for help) to resolve this problem.
The shell builtin 'printf' is used to print the executed command
line to ensure verbatim output.
At least Fedora and Debian now use
/usr/share/bash-completion/completions now. Apparently
/etc/bash_completion.d will be phased out at some point in the future.
Make test-lib-common.sh load test-lib-<$PLATFORM>.sh to create
additional shim for platform specifics.
Use test-lib-FREEBSD.sh to call GNU utilities instead of native ones.
- amended by db following Tomi's suggestions
In addition to use ${srcdir} and deliver ${NOTMUCH_SRCDIR} where needed,
source from ruby bindings had to be copied to the out-of-tree target
directory -- if the source files in source directory were referenced
in build and there were also built object files there, those could have
been considered as target files (and then not found when attempting
to create bindings/ruby/notmuch.so).
The ${srcdir} -- usually relative path to notmuch source -- works fine
in current ./configure and all makefiles. To have simple access to
notmuch source in tests and out of tree builds holding absolute path to
the source directory is useful.
When pkg-config does not find configure, a compat version of the
zlib.pc is created. In creation of that configure attempted to
read values of $zlib_cflags and $zlib_ldflags. In the usual case
those were undefined, and with `set -a` now in the beginning of
configure, configure broke.
Even if $zlib_cflags and $zlib_ldflags had values which were used
to create zlib.pc, the values were overwritten (with static content)
a few lines later in next pkg-config --cflags and --libs run. These
values would not be different and probably useless -- the following
boild would probably fail.
But instead of using those, CPATH and LIBRARY_PATH environment
variables can be used successfully (both while configuring and
building).
This is primarily intended for use in the test suite (since notmuch
builds fine without gnupg installed). Thus we only write the variable
to sh.config.
Removing the removal of byteorder configure test files was overlooked
in commit 5a957c3f33 ("build & util: drop byte order configure check
and endian util header"). Finish the job.
With the removal of the embedded libsha1, we lost the first and last
user of the platform byte order checks. Remove them from configure,
and remove the endian util header.
Since the sed expansion line which did $prefix expansion for
libdir_expanded was changed from the legacy `...` format to the
new $(...) expression, the subtle backslash expansion change went
unnoticed -- \\$ which used to escape '$' now escapes '\' and the
following '$prefix' was attempted to expand as a variable. So
changing \\$ to \$ fixes this.
Also, replaced echo with printf %s -- echo does expansions of its own.
While at it, the following 2 inconsistencies were fixed:
1) the /g flag was removed from first expression; second didn't have it
2) first expression did not end with /, so "dropped" it from second
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
There is really no need to have a separate install target for the
desktop file. Just install the desktop file with emacs, with a
configure option to opt out.
It seems that no-one tried to compile without Xapian compact support
since March of 2015, since that's when I introduced a syntax error in
that branch of the ifdef.
Given the choice of maintaining this underused branch of code, or
bumping the Xapian dependency to a version from 2011, it seems
reasonable to do the latter.
Since commit
124a67e96e: configure: add set -u
all variables must be set before their expansion are attempted. These
2 variables: "platform" and "linker_resolves_library_dependencies" were
not given value in the final 'else' branch when platform check failed
due to unrecognized kernel name (output of `uname`). Now those two are
given reasonable non-empty values.
Add option to explicitly disable API man page build even if doxygen
binary is available. --without-docs also implies not building API
manpage.
This change intended to add more distinctness into build system and
allow user not to build unwanted man pages.
