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.
It's probably a bit more work to use this configure script without
pkg-config, but it's at least possible, (and we could make it even
easier if this becomes an important use case).
Previously, we were resolving these within the Makefile. This had
the problem that if pkg-config was not present, the Makefile would
still invoke it resulting in ugly errors before the configure script
was even run, (which would finally present a kind error message about
pkg-config not being present).
This keeps configure-related clutter out of the main directory, and
also gives a more direct correlation between the name of the test and
the feature being tested for.
We're now using printf to print what we're checking before we check. We're
also making variables such as HAVE_GETLINE available to both make and to
the C pre-processor.
With this, the local getline implementation is now only compiled if not
available on the system.
Add a simple test to the configure script to detect getline. It's not
important that the test run, just that it compiles and links without
any errors.
Signed-off-by: Jeffrey C. Ollie <jeff@ocjtech.us>
We were missing an "override" directive in the assignment of CFLAGS
within Makefile.config so it was actually having no effect. Then, we
were also failing to get the proper include path for valgrind.h so
it wouldn't have worked even it were having effect. Fix both problems.
We had avoided using "echo -n" originally for portability concerns,
and instead just printed the same string in both conditions, (and
also printed the string late if any check took long). The word is
that printf is quite portable, so we use that instead.
It was problematic to have this in "make install" since it would
unconditionally try to install to /etc, (even if a non-privileged user
was attempting an install to a prefix in the user's home directory,
for example).
I felt sorry for Carl trying to step through an exception from xapian
and suffering from the SIGALARMs..
We can detect if the user launched notmuch under a debugger by either
checking our cmdline for the presence of the gdb string or querying if
valgrind is controlling our process. For the latter we need to add a
compile time check for the valgrind development library, and so add the
initial support to build Makefile.config from configure.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Carl Worth <cworth@cworth.org>
[ickle: And do not install the timer when under the debugger]
This is *not* based on autoconf. In fact, this doesn't actually
configure anything, (one can compile notmuch directly with just
"make" without running configure if the dependencies are all
satisfied).
The only thing that this configure script does is to check for the
presence of the various dependencies and provide some guidance to
the user if they are not all available.
