This is mainly for the test suite. We already expect the tests to be
run in the same environment as configure was run, at least to get the
name of the python interpreter. So we are not really imposing a new
restriction.
Checking the existence of timegm() function and setting
configure internal variable ${have_timegm} was done, but
actually defining HAVE_TIMEGM in build was not done --
meaning that compat timegm() was always part of final
notmuch binaries.
This does not play well with --prefix. As Tomi notes in
id:m2k2p2rwth.fsf@guru.guru-group.fi, people still have the option of e.g.
% ./configure ---emacslispdir=`pkg-config emacs --variable sitepkglispdir`
It's becoming a maintenance burden to do anything things with the
crypto glue code twice, once for 2.4 and once for 2.6. I don't have
any 2.4 version available to test on my development machine anymore,
so the 2.4 specific code paths are likely not very well tested.
- 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
The configure script chooses "python" if both python and python{2,3}
exist exists, so this could change the version of python used to run
the test suite.
The checking for ${NOTMUCH_PYTHON} in the test suite is arguably
over-engineering, since the configure step will fail if it can't find
it.
Previously documentation was build automatically if sphinx/doxygen
executable were found. The switch is used to unconditionally disable
sphinx/doxygen detection and therefor, building of documentation
(including man pages).
Because ruby generates a Makefile, we have to use recursive make.
Because mkmf.rb hardcodes the name Makefile, put our Makefile{.local}
in the parent directory.
Passing in environment variables incompatible with the compiler may
cause other parts of the configure script to fail in hard to
understand ways, so we abort early.
When the shell builtin `command -v` operates normally, it either
prints the path of the arg given to it and returns zero -- or it
returns nonzero and prints nothing.
In abnormal situations something might be printed to stderr and
in that case we want to know about it; therefore the used
command -v stderr redirections to /dev/null have been removed.
The `hash` (builtin) command in ksh returns zero even the arg
given to is is not found in path. For that and for consistency
the one appearance of it has been converted to `command -v`.
Currently we hardcode "python" in several places. This makes things
hard for people who have only commands called python3 and/or
python2. We also add the name to sh.config to eventually replace the
current workaround in the test suite.
There was theorical possibility that writing the config files could
have skipped (by interruption) after the instructions how to make
notmuch was printed out.
Some systems (e.g. FreeBSD 10) do not ship with the GNU Compiler
Collection. Use generic cc/c++ instead of gcc/g++ (unless the
CC/CXX environment variables are used).
Some systems (e.g. FreeBSD) might not have installed the appropriate
pkg-config file as they should. We can workaround the issue by creating
the .pc file they should have distributed.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
The main goal is to support gzipped output for future internal
calls (e.g. from notmuch-new) to notmuch_database_dump.
The additional dependency is not very heavy since xapian already pulls
in zlib.
We want the dump to be "atomic", in the sense that after running the
dump file is either present and complete, or not present. This avoids
certain classes of mishaps involving overwriting a good backup with a
bad or partial one.
the POSIX 2008 behaviour of realpath is not available everywhere so we
provide a simple wrapper function. We use (and provide) the gnu
extension canonicalize_file_name to make it cleaner to test for the
feature we need; otherwise we have to rely on realpath segfaulting if
the second argument is null.
The subtle part is adding .rst and .py files to vpath so they can be
used as dependencies without prefixing with $(srcdir)
We also change the interface to mkbuildeps.py: rather than getting the
containing directory from the conf file path, we go the other way.
Because sphinx-build does not provide a convenient way of listing
which builders exist, and some people actually have pre 1.0 sphinx, we
try loading a relevant python module.
Currently the assumption is that no python in path -> no sphinx-build
in path.
Support for dirent.d_type is OS-specific. Previously, we used
_DIRENT_HAVE_D_TYPE to detect support for this, but this is apparently
a glic-ism (FreeBSD, for example, supports d_type, but does not define
this). Since there's no cross-platform way to detect support for
dirent.d_type, detect it using a test compile at configure time.
Unfortunately old versions of GCC and clang do not provide byte order
macros, so we re-invent them.
If UTIL_BYTE_ORDER is not defined or defined to 0, we fall back to
macros supported by recent versions of GCC and clang
This function uses Xapian's Compactor machinery to compact the notmuch
database. The compacted database is built in a temporary directory and
later moved into place while the original uncompacted database is
preserved.
Signed-off-by: Ben Gamari <bgamari.foss@gmail.com>
The timegm(3) function is a non-standard extension to libc which is
available in GNU libc and on some BSDs. Although SunOS had this
function in its libc, Solaris (unfortunately) removed it. This patch
implements a very simple version of timegm() which is good enough for
parse-time-string.c.
Signed-off-by: Vladimir Marek <vlmarek@volny.cz>
Solaris does not ship a version of the strsep() function. This change
adds a check to "configure" to see whether notmuch needs to provide its
own implementation, and if so, it uses the new version in
"compat/strsep.c" (which was copied from Mutt, and apparently before
that from glibc).
Signed-off-by: Vladimir Marek <vlmarek@volny.cz>
Add checks to "configure" to see whether _POSIX_PTHREAD_SEMANTICS needs
to be defined to get the right number of arguments in the prototypes for
asctime_r(). Solaris' default implementation conforms to POSIX.1c
Draft 6, rather than the final POSIX.1c spec. The standards-compliant
version can be used by defining _POSIX_PTHREAD_SEMANTICS.
This change also adds the file "compat/check_asctime.c", which
configure uses to perform its check, and modifies compat/compat.h to
define _POSIX_PTHREAD_SEMANTICS if configure detected it was needed.
Signed-off-by: Vladimir Marek <vlmarek@volny.cz>
Add checks to "configure" to see whether _POSIX_PTHREAD_SEMANTICS needs
to be defined to get the right number of arguments in the prototypes for
getpwuid_r(). Solaris' default implementation conforms to POSIX.1c
Draft 6, rather than the final POSIX.1c spec. The standards-compliant
version can be used by defining _POSIX_PTHREAD_SEMANTICS.
This change also adds the file "compat/check_getpwuid.c", which
configure uses to perform its check, and modifies compat/compat.h to
define _POSIX_PTHREAD_SEMANTICS if configure detected it was needed.
Signed-off-by: Vladimir Marek <vlmarek@volny.cz>
It turns out that if people really use configure in autotools style and pass
libdir containing '${prefix}/foo' then the ldconfig previously failed.
This uses sed for portability (versus bash parameter expansion with
substitution) and hopefully a bit more robustness than blindly
parameter expanding the string.
-Wswitch-enum is a bit awkward if a switch statement is intended to
handle just some of the named codes of an enumeration especially, and
leave the rest to the default label.
We already have -Wall, which enables -Wswitch by default, and per GCC
documentation, "The only difference between -Wswitch and this option
[-Wswitch-enum] is that this option gives a warning about an omitted
enumeration code even if there is a default label."
Drop -Wswitch-enum to not force listing all named codes of
enumerations in switch statements that have a default label.
OpenBSD's build flags are identical to FreeBSD, except that libraries
need to be explicitly linked against libc. No code changes are
necessary.
From: Cody Cutler <ccutler@csail.mit.edu>
'configure' script uses parameter substring extensively. It is Posix shell
feature. Original Bourne shell does not have such features. Some systems
still ships such shells as /bin/sh (for compatibility reasons -- shell
scripts written on those platforms are expected to work on 1990's systems).
Just testing whether parameter substring processing works will make the
shell exit due to syntax error if it is not compatible. Therefore the test
is executed in a subshell -- subshell exits with nonzero value when the
operation in question fails.
As 'if ! ...' does not work in Bourne shell, Short-circuiting construct
'||' is used to print information message and exit when expected.
Without proper quoting the DEFAULT_IFS was getting set incorrectly,
which was causing problems with the storage of some variables later in
the script. Quoting fixes the problem.
Since GMime 2.6 is now the stable version upstream, and probably the
most tested by notmuch developers, it makes sense to suggest that to
users to install.
Currently whenever message about missing GMime, Glib or talloc is
printed the message is 2 lines, component info and its http location
in next line. In the future the amount of lines will vary. To ease
reading in these cases newline is added after each message.
This allows for testing against both versions of gmime on a single
machine, without having to mess with pkg-config paths.
This is rework of Tom Prince's patch submitted in
id:"1331402091-15663-1-git-send-email-tom.prince@ualberta.net"
In the future, IFS value needs to be changed in a few places
in configure -- and then restored. Store the original value
to $DEFAULT_IFS for easy restoration.
Formerly the code assumed the arguments to be triples and threw an
error if this was not the case. But those arguments are only there for
compatibility with autotools and are not used within the build system,
so just dropping the code parsing these values makes the build system
more robust.
Signed-off-by: Justus Winter <4winter@informatik.uni-hamburg.de>
gmime-2.6 had a bug [1] which made it impossible to tell why a signature
verification failed when the signer key was unavailable (empty "sigstatus" field
in the JSON output). Since 00b5623d the corresponding test is marked as broken
when using gmime-2.6 (2.4 is fine).
This bug has been fixed in gmime 2.6.5, which is now the minimal gmime-2.6
version required for building notmuch (gmime-2.4 is still available). As a
consequence the version check in test/crypto can be removed.
[Added by db]
Although less unambigously a bug, Gmime 2.6 prior to 2.6.7 also was
more strict about parsing, and rejected messages with initial "From "
headers. This restriction is relaxed in [2]. For reasons explained in [3],
we want to keep this more relaxed parsing for now.
[1] https://bugzilla.gnome.org/show_bug.cgi?id=668085
[2] http://git.gnome.org/browse/gmime/commit/?id=d311f576baf750476e06e9a1367a2dc1793ea7eb
[3] id:"1331385931-1610-1-git-send-email-david@tethera.net"
Previously, the configure script would appear to detect gmime-2.6 if
present. However, the binaries would end up being compiled against
gmime-2.4. The addition of a break fixes things so that now gmime-2.6
will be used if available, falling back to gmime-2.4.
As of commit b3caef1f, we're using g_array_unref() in 'lib/query.cc',
which was only introduced in glib 2.22, so update the dependency.
Thanks to datapipe@gmail.com for reporting this [1].
Also see commit b88e6abc.
[1] id:"alpine.DEB.2.02.1201132130220.21970@ltspubuntu4.int.smq.datapipe.net"
Various typo fixes in comments within the Makefile and other build scripts.
Signed-off-by: Pieter Praet <pieter@praet.org>
Edited-by: Carl Worth <cworth@cworth.org> Restricted to just build files.
Ever since commit b4b5e9ce4d the
detection of libdir in the ldconfig configuration has been broken,
resulting in RPATH being set when not needed and not wanted.
The cause was a change from an IFS setting of:
IFS="$(printf '\n\t')"
to a new setting of:
IFS="$(printf '\n')"
That looks desirable since we want to split the output of ldconfig
based on newlines, (and not split on any filename that might have an
embedded tab in it). The subtle bug in the above is that the shell
trims any trailing newlines when performing command substitution so
the final statement above was equivalent to:
IFS=''
which prevented any splitting of the ldconfig output at all.
Fix this by avoiding command substitution and just using a literal
newline in the source file for setting this variable.
This supports the case of a user running "configure --prefix=/foo" then later
updating the soruce (including the configure script) and re-running make.
In this case, the make invocation will re-run configure. Before this change,
this run of configure would lose the user's carefully chosen prefix. This
is now fixed so that configrue is re-run with the user's options.
Such as:
mkdir build
cd build
../configure
make
This is implemented by having the configure script set a srcdir
variable in Makefile.config, and then sprinkling $(srcdir) into
various make rules. We also use vpath directives to convince GNU make
to find the source files from the original source directory.
This was originally intended to help support filenames with spaces in
them, but this actually breaks things when someone sets a command with
a space in it, (such as CC="ccache cc").
Instead, we now only set a custom IFS when acting on the
newline-separated list of files from /sbin/ldconfig.
add --bashcompletiondir and --zshcompletiondir (like --emacslispdir) to choose
installation dir for bash/zsh completion files
Make some features optional:
--without-emacs / --with-emacs=no do not install lisp file
--without-bash-completion / --with-bash-completion=no do not install bash
files
--without-zsh-completion / --with-zsh-completion=no do not install zsh files
By default, everything is enabled. You can reenable something with
--with-feature=yes
With --modversion we were asking for output that we were just throwing
away anyway. The --exists option does just what we want, (no output
and communivating only via return value).
Also, --exists allows for testing versions of the package as well.
This fits with our general build philosophy of checking at configure
time for desired support, (rather than putting platform-specific
conditionals into our Makefiles).
Previously, we preferred a value of "xapian-config-1.1" first. This
was convenient for compiling against Xapian 1.1 while Xapian 1.2 was
unreleased. But now that Xapian 1.2 is realease, and since it ships a
xapian-config, the xapian-config-1.1 value can mask the newer library.
Instead of trying to track the latest xapian-config-1.x in our
configure script let's simply expect the user to set
XAPIAN_CONFIG=xapian-config-1.x in order to compile against an
unreleased Xapian.
Various users were confused as to why they couldn't run notmuch
immediately after "make install", (with linker errors saying that
libnotmuch.so could not be found). The errors came from two different
causes:
1. The user had installed to a system library directory, but had not
yet run ldconfig.
2. The user had installed to some non-system directory, and had not
set the LD_LIBRARY_PATH variable.
With this change we fix both problems (on Linux) without the user
having to do anything additional. We first use ldconfig to find the
system library directories. If the user is installing to one of these,
then we run ldconfig as part of "make install".
For case (2) we use the -rpath and --enable-new-dtags linker options
to install a DT_RUNPATH entry in the binary. This entry tells the
dynamic linker where to find libnotmuch. Without the
--enable-new-dtags option only a DT_RPATH option would be installed,
(which has the drawback of not allowing any override with the
LD_LIBRARY_PATH variable).
Distributions (such as Debian and Fedora) don't want to see binaries
packaged with a DT_RPATH or DT_RUNPATH entry. This should be avoided
automatically as long as the packages install to standard locations,
(such as /usr/lib).
The idea here is to more easily support filenames with spaces in them
in various loops. We're about to add a loop over the paths configured
by the dynamic linker. Hopefully, they wouldn't contain spaces, but
one never knows so we might as well be prepared.
The configure usage string documents that it respects LDFLAGS, but
currently it doesn't do anything with the configure-time LDFLAGS
value.
Signed-off-by: Tomas Carnecky <tom@dbservice.com>
[Tomas and Nelson sent almost identical patches which I've merged
together here.]
This way when GMime 2.8 comes out we can simply add it to the list
rather than adding an additional block of conditional code for it.
Also GMime 2.6 is now preferred over GMime 2.4.
Before and after the assignment operator, no spaces are allowed.
I don't know if there are any /bin/sh which allow spaces, but at least
in bash, csh and zsh, the former code was no valid assigment.
Apparently the OS X linker can't resolve symbols when linking a
program (notmuch) against a library (libnotmuch) when the library
depends on another library (libgmime) that the program doesn't depend
on directly.
For this case, we need to link the program directly against both
libraries, but we don't want to do this on Linux, where the linker can
do this on its own and the explicit, unneeded link would cause
problems.
This patch adds a configure check for OS X (actually Darwin),
and sets up the Makefiles to build a proper shared library on
that platform.
Signed-off-by: Aaron Ecay <aaronecay@gmail.com>
While all systems that I have access to support strcasestr, it is
in fact not part of POSIX. So here's a fallback reimplementation
based on POSIX functions.
Signed-off-by: Dirk Hohndel <hohndel@infradead.org>
Tested-by: Tomas Carnecky <tom@dbservice.com> (on OpenSolaris snv_134)
And just make the Debian packaging request site-lisp/notmuch like it
wants. Otherwise, the installed files won't appear on the load-path
so won't be found by emacs.
Which means that the bash completion script will now install
to ${prefix}/etc by default (unless configured with --syconfdir=/etc)
which is probably the right thing to do.
I'm not sure that this option would actually be useful for anything,
but debhelper at least expects our configure script to support it. So
we'll accept it and ignore it.
It makes sense to me to have the little tests for functionality right
next to the comptability implementations of that same functionality.
But also, this means I can now tab-complete ./configure from the three
initial characters (rather than the seven required previously).
Instead, simply byte-compile the emacs source files as part of "make"
and install them as part of "make install". The byte compilation is
made conditional on the configure script finding the emacs binary.
That way, "make; make install" will still work for someone that doesn't
have emacs installed, (which was the only reason we had made a separate
"make install-emacs" target in the first place).
