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
This option wasn't having the desired effect, and sure enough, the
documentation states that it only affects the linking of libraries
that appear after this option on the command line. So put it early for
the desired effect.
This prevents any of the private functions from being leaked out
through the library interface (at least when compiling with a
recent-enough gcc to support the visibility pragma).
Previously, we were building the final binary with this option, but not
the library. The library can benefit from it as well, (as pointed out
by Debian's lintian).
This fits with our general build philosophy of checking at configure
time for desired support, (rather than putting platform-specific
conditionals into our Makefiles).
Without this, trying to link with the gold linker would fail, (which meant
that notmuch could not be compiled out of the box on recent Fedora, nor
even on Debian when the binutils-gold package is installed).
This avoids "make test" emitting messages from three (3!) recursive
invocations of make. We change the invocations of the tests themselves
to occur directly from the shell script rather than having the shell
script invoke make again and using wildcards in the Makefile.
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).
This was already telling the user how to run notmuch within emacs, but
not how to just run the notmuch command-line interface, (which, as it
turns out, is a prerequisite for running the emacs interface anyway).
So add a small paragraph here.
Eventually I'd like to automate this so that one or the other of these
files is canonical and the other is generated from it. Until then, add
this check to the release process to avoid a skewed release being
shipped.
On Linux, a C program that depends on a C library which in turn
depends on a C++ can be linked with the C compiler, (avoiding a direct
link from the program to the C++ runtime libraries).
Other platforms with less fancy linkers need to use the C++ compiler
for this linking.
Useful for verifying that our tar-file creation works. The tar-file
name can't easily be used as a target directly since it depends on the
current git revision.
Theese were previously pointing to "make VERSION=X.Y release", but
we've recently changed to an alternate scheme involving the updated
version in a file named "version".
We do this so that "git archive" produces a usable tar file without us
having to post-modify it, (since tools like git-buildpackage might not
give us an easy way to hook into the tar-file-creation step).
To support this we also have to change our preference to prefer the
git-described-based version (if available) and only if not available
do we fallback to using what's in the "version" file. Finally, we also
ovverride this preference when releasing, (where what's in the
"version" file wins).
Note that using our Makefile's rule to create a tar file still will
insert the git-based version into the tar file. This is useful for
creating snapshots which will correctly report the git version from
which they were created.
We put verify-version as a dependency, not a recursive action to keep
its output clean, (I know that I will always type "make release"
instead of "make VERSION=X.Y release" so I want a nice, neat
reminder).
Also, put the various ssh-based commands together, and after the
build, (so that it doesn't ask for a password/passphrase both before
and after building).
Previously, we had a separate release-upload target that a user might
mistake as something useful to call directly, (which would have the
undesired effect or uploading a new package, but without first making
all the checks that we want).
So we eliminate that target, (folding its actions into "make
release"), and we also rename the several release-verify-foo targets
to simply verify-foo. This leaves as the only targets with "release"
in the name as "release" and "release-message". Both of these are
intended for the user to call directly.
I just wasted far too much time looking for a bug that wasn't actually
there only because I hadn't recompiled before running the test
suite. Now we can take advantage of actual dependency information to
force a rebuild for "make test".
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>
The recent change to include sub-directory Makefile.local files
before the top-level Makefile.local means that we need to include
the Makefile.config before those. So move it up from Makefile.local
to Makefile.
Must set extra_c(xx)flags before including subdir Makefile.local's,
so that there is a blank slate that the subdirs can add on to.
Must include subdir Makefile.local's before global one, otherwise
the compat sources are not added to the list of those to be
compiled.
Signed-off-by: Aaron Ecay <aaronecay@gmail.com>
Since the binaries contain C++ code, it is necessary to use the C++
linker, or errors result on some platforms (OS X).
Signed-off-by: Aaron Ecay <aaronecay@gmail.com>
When headers contain non-ASCII characters, they are encoded according
to rfc2047. Nomtuch reply command emits the headers in the encoded
form, which makes them hard to read by humans who compose the reply.
For example instead of "Subject: Re: Rozlučka" one currently sees
"Subject: Re: =?iso-8859-2?q?Rozlu=E8ka?=".
This patch adds a new GMime filter which is used to decode headers to
UTF-8 and uses this filter when notmuch reply outputs headers.
Signed-off-by: Michal Sojka <sojkam1@fel.cvut.cz>
I often have several versions of notmuch compiled and it would be very
helpful to be able to distinguish between them. Git has a very nice
feature to make intermediate numbering automatic and unambiguous so
let's use it here.
For tagged versions, the version is the name of the tag, for
intermediate versions, the unique ID of the commit is appended to the
tag name.
When notmuch is compiled from a release tarball, there is no git
repository and therefore the tarball contains a special file 'version',
which contains the version of release tarball.
To create a new release one has to run 'make release VERSION=X.Y'.
These are the changes made between the notmuch 0.1 release and the
release of Debian version 0.1-1. It's mostly changes to the debian
directory, of course, but does also include some generally useful
Makefile improvements.
We currently don't distribute anything that's not already in git, so
there's no difference between these two targets, (but debhelper wants
to be able to call distclean).
Again, simplifying the interface to the Makefile. Installing these
files doesn't require bash nor zsh to actually be installed, so there's
little harm in just installing them unconditionally.
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.
For other projects I release, there's a bunch of manual effort in
cosntructing the final release-announcement email. That's silly.
So automate this by extracting the appropirate text from NEWS and
by including a canned piece of the content from README.
This is a merge of the few changes I made to release 0.1
retroactively, (after having incremented the version to 0.1.1).
Conflicts:
Makefile.local (renamed NOTMUCH_VERSION to VERSION)
We add a magic line to the beginning of each Makefile.local file to
help the editor know that it should use makefile mode for editing the
file, (even though the filename isn't exactly "Makefile").
Edited-by: Carl Worth <cworth@cworth.org>: Expand treatment from
emacs/Makefile.local to each instance of Makefile.local.
Reviewed-by: Carl Worth <cworth@cworth.org>: Presumably, this is to
enable proper building in the very near-term future where the emacs
implementation consists of multiple files where some will `require'
functions from others.
It was getting quite annoying to see this big block of text on every
little build, (but I didn't want to get rid of it for any new users).
This seems to strike the right balance.
The idea here is to allow a new user of notmuch to be able to run
notmuch immediately after compiling, (without having to install
the shared library first). This also ensures that the test suite
tests the locally compiled library, and not whatever installled
version of the library the dynamic linker happens to find.
The default "make" would be quite quiet, but still conveniently print
the CFLAGS. The explicit "make V=0" was intended to be identical, (only
not printing the message about V=1 but was broken in that it left the
CFLAGS off). Fix this.
We had a fairly ugly violation of modularity with the top-level
Makefile.local isntalling everything, (even when the build commands
for the library were down in lib/Makefile.local).
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.
Before it was impossible to know whether any particular setting or
rule definition was in Makefile or Makefile.local. So we strip the
Makefile down to little more than the list of sub-directories and
the logic to include all of the sub-directories' Makefile.local
fragments.
Then, all of the real work can happen inside of Makefile.local.
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.
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.
In the case of notmuch-show, "--format=json" also implies
"--entire-thread" as the thread structure is implicit in the emitted
document tree.
As a coincidence to the implementation, multipart message ID numbers are
now incremented with each part printed. This changes the previous
semantics, which were unclear and not necessary related to the actual
ordering of the message parts.
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>
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>
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.
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 is a new notmuch command that can be used to search for all tags
found in the database. The resulting list is alphabetically sorted.
The primary use-case for this new command is to provide the tag
completion feature in Emacs (and other interfaces).
Signed-off-by: Jan Janak <jan@ryngle.com>
Getting the count of matching threads or messages is a fairly
expensive operation. Xapian provides a very efficient mechanism that
returns an approximate value, so use that for this new command.
This returns the number of matching messages, not threads, as that is
cheap to compute.
Signed-off-by: Keith Packard <keithp@keithp.com>
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]
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]
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>
Previously, Ubuntu 9.10, gcc 4.4.1 was getting:
/usr/bin/ld: lib/notmuch.a(database.o): in function global
constructors keyed to BOOLEAN_PREFIX_INTERNAL:database.cc(.text+0x3a):
error: undefined reference to 'std::ios_base::Init::Init()'
Do not use -C cmdline option of install, older versions, commonly found in
distributions like Debian, do not seem to support it. Running make install
on such systems (tested on Debian Lenny) fails.
Signed-off-by: Jan Janak <jan@ryngle.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.
I was confusing myself with some rules installing to directories and
some installing to files. We do still install to a filename when
simultaneously renaming, (such as notmuch-completion.bash to notmuch).
