We were previously maintaining two lists of the child Makefile
fragments---one for the includes and another for the dependencies. So,
of course, they drifted and the dependency list wasn't up to date.
We fix this by adding a single subdirs variable, and then using GNU
Makefile substitution to generate both the include and the dependency
lists.
Some side effect of this change caused the '=' assignment of the dir
variable to not work anymore. I'm not sure why that is, but using ':='
makes sense here and fixes the problem.
We wamt a simple "make" to call the 'all' target and then print a
message when done, but we don't want "make install" which depends on
that same 'all' target to print the message.
We previously did this with a separate 'all-without-message' target,
which was inelegant because it caused all users of the target to
carefully depend on 'all-without-message' rather than 'all'.
Instead, we now use a single 'all' target but with a Makefile
conditional that examines the MAKECMDGOALS variable to determine
whether to print the message.
The "all" inside this variable name was easy to confuse with the
separate "all" target. This variable specifies dependencies that apply
to every target, so use "global" instead.
Add emacs/Makefile.local and emacs/Makefile. Move emacs targets into
emacs/Makefile.local, but leave the byte compilation rule in the top
level Makefile.
According to the Debian zsh maintainer Clint Adams, this is the first
time that a package installs its own completer into zsh. Part of the
reason this is not usually done is because zsh does not provide a stable
API.
We agreed to try it, given that notmuch is expected to change quite
a bit initially. If there are problems or the completer goes stable,
we'll move it into the upstream zsh repository.
Signed-off-by: martin f. krafft <madduck@debian.org>
We have a bootstrapping issue with our dependency generation. When the
Makefile.config doesn't exist yet, the complete compilation flags are
not yet available for passing to the compiler to generate the
dependencies.
But we don't have explicit rules to create these dependency files,
(just the implicit rule that is created by the -include), so we can't
control when make will attempt to create them.
We do have a dependency of the dependency files on Makefile.config, so
make should eventually call the compiler with the correct flags and
everything should be good. So in the meantime, silence any complaints.
If the Makefile does this for the user, then no arguments are passed. So
it's only polite to let the user know that it's possible to get pass those
arguments.
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.
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).
Some systems have an echo implementation which doesn't know how to
interpret a sequence of "\n". The word is that printf should be much
more portable, so let's try that instead.
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.
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).
This ensures that make clean always proceeds, even if the user
accidentally creates a file named 'clean'. Also, it ignores errors in
rm and other commands.
Signed-off-by: Jan Janak <jan@ryngle.com>
The rule here was written to assume that if the GZIP environment
variable was set that it would be the gzip binary to execute,
(similar to the CC and CXX variables). But GZIP is actually used
to pass arguments to gzip, so we have to use a different name.
Use the facilities of GNU make to create a magic function that will
on the first invocation print a description of how to enable verbose
compile lines and then print the quiet rule.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Carl Worth <cworth@cworth.org>
Cc: Mikhail Gusarov <dottedmag@dottedmag.net>
[ickle: Rebased, and duplicate command string eliminated.]
[ickle: Fixed verbose bug pointed out by Mikhail]
When pkg-config can't be used to find out where to install emacs
files, we fallback to a hard-coded directory. Only, we were falling
back to the wrong thing, (one that emacs doesn't look into by
default).
All objects need to be recompiled when any of the Makefiles changes, so
we make them all depend on all the Makefiles.
Signed-off-by: Jan Janak <jan@ryngle.com>
This was added in a prelimnary version of a previous commit that would
automatically load notmuch.el for anyone running emacs. It's not used
at all in the current Makefile.
1) Add a separate targets to build and install emacs mode.
2) Don't hardcode the installation directory, instead use emacs'
pkg-config module.
3) Install a byte compiled version of the emacs mode.
4) Install the emacs mode in emacs' site-lisp directory. Put
"(require 'notmuch)" in your .emacs to load it automatically.
5) Ignore byte-compiled emacs files.
Signed-off-by: Jeffrey C. Ollie <jeff@ocjtech.us>
Reviewed-by: Ingmar Vanhassel <ingmar@exherbo.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
We'll be a much more polite package this way. And the user can change
the prefix by editing Makefile.config. Still to be done is to make
configure write out Makefile.config and to add a --prefix option to
configure.
Otherwise, things in the lib sub-directory weren't getting recompiled
even when lib/notmuch.h was changed.
The original rule we were using came from the GNU Makefile manual, but
only handled files in the current directory, not file in
sub-directories as we use here with our non-recursive Makefile.
So the .deps files being created were being put in the right place,
(such as .deps/lib/database.d), but the compiler was generating a
dependency for "database.o" rather than "lib/database.o" like we
want. We were already trying to do a sed job on that name to add a
dependency for the .d file as well. But the sed job was failing since
the expected pattern wasn't there, (the directory name was missing).
So the fix is simply to use basename to construct the search pattern,
and then use the name with the directory in the replacement (rather
than the back-reference).
Previously, the top-level Makefile was explicitly adding -I./lib to
the compiler flags. However, that's something that's much better done
from within the Makefile.local fragment within the lib directory
itself.
We were previously using separate CFLAGS and NOTMUCH_CFLAGS variables
in an attempt to allow the user to specify CFLAGS on the command-line.
However, that's just a lot of extra noise in the Makefile when we can
instead let the user specify what is desired for CFLAGS and then use
an override to append the things we require. So our Makefile is much
neater now.
I saw this recommendation in the implementation notes for "Recursive
Make Considered Harmful" and then the further recommendation for
implementing the idea in the GNU make manual.
The idea is that if any of the files change then we need to regenerate
the dependency file before we regenerate any targets.
The approach from the GNU make manual is simpler in that it just uses
a sed script to fix up the output of an extra invocation of the
compiler, (as opposed to the approach in the implementation notes from
the paper's author which use a wrapper script for the compiler that's
always invoked rather than the compiler itself).
The idea here is that every Makefile at each lower level will be an
identical, tiny file that simply defers to a top-level make.
Meanwhile, the Makefile.local file at each level is a Makefile snippet
to be included at the top-level into a large, flat Makefile. As such,
it needs to define its rules with the entire relative directory to
each file, (typically in $(dir)). The local files can also append to
variables such as SRCS and CLEAN for files to be analyzed for
dependencies and to be cleaned.
Instead of the old name of Makefile.dep. The idea being that the
user really doesn't need to see this by default, (and if debugging
the Makefile, the rules will make the name obvious).
We had originally copied this function in at a time when notmuch
wasn't actually depending on the GMime library. Now that it does,
we might as well call the function that exists there rather
than having a private copy of it.
This is based on the old notmuch-index-message.cc from early in
the history of notmuch, but considerably cleaned up now that
we have some experience with Xapian and know just what we want
to index, (rather than just blindly trying to index exactly
what sup does).
This does slow down notmuch_database_add_message a *lot*, but I've
got some ideas for getting some time back.
We want to start using this from both message.cc and thread.cc so we
need it in a place we can share the code. This also requires a new
notmuch-private-cxx.h header file for interfaces that include
C++-specific datatypes (such as Xapian::Document).
We've now got a new notmuch_query_search_threads and a
notmuch_threads_result_t iterator. The thread object itself
doesn't do much yet, (just allows one to get the thread_id),
but that's at least enough to see that "notmuch search" is
actually doing something now, (since it has been converted
to print thread IDs instead of message IDs).
And maybe that's all we need. Getting the messages belonging
to a thread is as simple as a notmuch_query_search_messages
with a string of "thread:<thread-id>".
Though it would be convenient to add notmuch_thread_get_messages
which could use the existing notmuch_message_results_t iterator.
Now we just need an implementation of "notmuch show" and we'll
have something somewhat usable.
I didn't notice this because `xapian-config -cxxflags` gives empty
output on my system. But for someone with the xapian library
installed in some non-standard location this would be important.
I didn't end up adding any of the warnings options that aren't allowed
for C++, (such as -Wold-style-definition, -Wnested-externs,
-Werror-implicit-function-declaration, -Wstrict-prototypes,
-Wmissing-prototypes, or -Wbad-function-cast). So for now we can
drop the separate C and C++ variables for warnings.
Having to enumerate all the enum values at every switch is annoying,
but this warning actually found a bug, (missing support for
NOTMUCH_STATUS_OUT_OF_MEMORY in notmuch_status_to_string).
