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).
With the original quiet function, there's an actual purpose (hiding
excessively long compiler command lines so that warnings and errors
from the compiler can be seen).
But with things like quiet_symlink there's nothing quieter. In fact
"SYMLINK" is longer than "ln -sf". So all this is doing is hiding the
actual command from the user for no real benefit.
The only actual reason we implemented the quiet_* functions was to be
able to neatly right-align the command name and left-align the arguments.
Let's give up on that, and just left-align everything, simplifying the
Makefiles considerably. Now, the only instances of a captialized command
name in the output is if there's some actually shortening of the command
itself.
One of the supproted mechanisms we offer for configuration is
manually editing the Makefile.config file after it is generated
by the configure script. In this case it would be nice to be able
to change prefix only once, so allow that.
There's not any special configure logic for determining these variable
values, but if we did add some in the future, then these will now be
in the right place for that.
Additionally, this now makes Makefile.local the single place for the
user to look for manually tweaking a variable assignment, (say, for a
compiler that can't accept a particular warning argument).
With this change, there should rarely be any need for a user to poke
into any Makefile.local file.
If an explicit --libdir is passed, then that is used directly. Otherwise
libdir is chosen as the value of $PREFIX/lib, (whether or not prefix was
passed explicitly or set by default).
Add an install target that uses desktop-file-install to install the
desktop file in the appropriate location. The location of the install
can be modified by changing the desktop_dir variable.
Signed-off-by: Jeffrey C. Ollie <jeff@ocjtech.us>
The in-development version of Xapian provides a config program named
xapian-config-1.1 while the released version provides a program named
xapian-config instead. By default, we now try each of these in turn,
and we also allow the user to set a XAPIAN_CONFIG environment variable
to explicitly specify a particular program.
These variables can now be set via configure time via environment
variables like so:
CFLAGS=-g ./configure
and subsequent builds will remember these values. The values can
still be overridden at compile time by passing make variables:
make CFLAGS=-O2
The CXXFLAGS variable is optional. If unset at either configure
time or at compile time, it will inherit its value from the
CFLAGS variable. (Though if explicitly set at configure time
it must be explicitly overriden at compile time---just overriding
CFLAGS will not override CXXFLAGS as well.)
The only reason I ever call "make V=1" myself, (other than when
debugging the compiler command-line for some reason), is to ensure
whether my CFLAGS, (like "-g -O0" or "-O2"), are actually making it to
the command-line.
But these are hard to find in the V=1 output, and really, we should
just print these even in the quiet case. So do that.
Reviewed-by: Carl Worth <cworth@cworth.org>:
This is really the fundamental thing that people expect a configure
script to do, so it's important to support it.
Add some text on how to install dependencies with yum for Fedora or
other systems that use yum for package management. Since the named of
the required packages on Fedora are slightly different from Debian
this will help get new users of notmuch that use Fedora going quicker.
Signed-off-by: Jeffrey C. Ollie <jeff@ocjtech.us>
The environment variables CC and CXX can be set at configure time to
specify what compiler to use. This compiler will be used for any
configure-time compilation, and will also be recorded in
Makefile.config to be used during the actual build.
The compiler to be used can still be overridden at build time by using
a make variable such as:
make CC=gcc
Each dependency now gets its own variable in the resulting
Makefile.config to make it much easier to debug where the various
flags came from in the case of any problems.
