Users may have set core.abbrev=n, where n != 7 in their git config
file(s) which would give them different than expected version strings
when building notmuch from git. This fixes the commit hash part of
version string to 7 hexadecimal values.
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.
This version file will be as prerequisite to the target files
that use the version info for some purpose, like printing
it for the user to examine. The contents of the version.stamp
file is seldom read by the build system itself as the $(VERSION)
variable has the same information.
Thanks to Trevor, David and Mark for their contributions.
This helps avoid build artifacts (namely, nroff and gzipped-nroff man
pages) owned by root.
The variables allow choosing which generator to use for the man page.
These will be hooked to configure in a following commit.
The python script mkdocdeps.py is used to import the list of man pages
from the sphinx configuration to make.
This will delete the (release only) target update-man-versions. This
will be replaced in a followup commit.
All implicit rules in notmuch Makefiles are "pattern rules"; Deleting the
default suffixes (to support obsolete, old-fashioned "suffix rules") from
make reduces the output of 'make -d' by 40 to 90 percent, helping e.g.
debugging make problems.
When make variable $@ does not contain directory part, $(@D)
resolves as '.'. In this case .deps/$(@D) is '.deps/.'
In some systems `mkdir [-p] directory/.` fails.
To make this compatible with more system substitute trailing
'/.' (slashdot) with '' (empty string) whenever it occurs there.
This ensures that the build will not attempt to use an existing notmuch.h when
an older version of notmuch is already installed elsewhere (e.g. in /usr/local)
and /usr/local/include is added to CONFIGURE_CFLAGS by one of the libraries
(talloc, in my case)
Previously, reply's default text format used an odd mix of RFC 2045
MIME encoding for the reply template's body and some made-up RFC
2822-like UTF-8 format for the headers. The intent was to present the
headers to the user in a nice, un-encoded format, but this assumed
that whatever ultimately sent the email would RFC 2047-encode the
headers, while at the same time the body was already RFC 2045 encoded,
so it assumed that whatever sent the email would *not* re-encode the
body.
This can be fixed by either producing a fully decoded UTF-8 reply
template, or a fully encoded MIME-compliant RFC 2822 message. This
patch does the latter because it is
a) Well-defined by RFC 2822 and MIME (while any UTF-8 format would be
ad hoc).
b) Ready to be piped to sendmail. The point of the text format is to
be minimal, so a user should be able to pop up the template in
whatever editor they want, edit it, and push it to sendmail.
c) Consistent with frontend capabilities. If a frontend has the
smarts to RFC 2047 encode the headers before sending the mail, it
probably has the smarts to RFC 2047 decode them before presenting
the template to a user for editing.
Also, as far as I know, nothing automated consumes the reply text
format, so changing this should not cause serious problems. (And if
anything does still consume this format, it probably gets these
encoding issues wrong anyway.)
The notmuch insert command reads a message from standard input,
writes it to a Maildir folder, and then incorporates the message into
the notmuch database. Essentially it moves the functionality of
notmuch-deliver into notmuch.
Though it could be used as an alternative to notmuch new, the reason
I want this is to allow my notmuch frontend to add postponed or sent
messages to the mail store and notmuch database, without resorting to
another tool (e.g. notmuch-deliver) nor directly modifying the maildir.
These are meant to be shared between notmuch-tag and notmuch-restore.
The bulk of the routines implement a "tag operation list" abstract
data type act as a structured representation of a set of tag
operations (typically coming from a single tag command or line of
input).
This commit adds a structured output printer for Lisp
S-Expressions. Later commits will use this printer in notmuch search,
show and reply.
The structure is the same as json, but:
- arrays are written as lists: ("foo" "bar" "baaz" 1 2 3)
- maps are written as p-lists: (:key "value" :other-key "other-value")
- true is written as t
- false is written as nil
- null is written as nil
[ whitespace changes by db ]
Use new target release-checks in place of verify-version-debian,
verify-version-python verify-version-manpage. This target executes
devel/release-checks.sh which does all the verifications the three
dropped targets did, and some more.
Create a variable DISTCLEAN which contains a list of things to
clean in the distclean target (in addition to running the clean
target).
The deleted comment seems to be false these days, since we do
create files during configuration.
Use "rm -rf" here as well in case we want to add directories to
DISTCLEAN.
These extra directories cause problems for building on Debian
twice in a row.
In order to remove directories, we need to us "rm -rf" instead of
"rm -f". So now we should be extra careful what we add to the
variable CLEAN.
Using the new structured printer support in sprinter.h, implement
sprinter_json_create, which returns a new JSON structured output
formatter. The formatter prints output similar to the existing JSON, but
with differences in whitespace (mostly newlines, --output=summary prints
the entire message summary on one line, not split across multiple lines).
Also implement a "structured" formatter for plain text that prints
prefixed strings, to be used with notmuch-search.c plain text output.
This new structure, notmuch_crypto_t, keeps all relevant crypto
contexts and parameters together, and will make it easier to pass the
stuff around and clean it up. The name of the crypto context inside
this new struct will change, to reflect that it is actually a GPG
context, which is a sub type of Crypto context. There are other types
of Crypto contexts (Pkcs7 in particular, which we hope to support) so
we want to be clear.
The new crypto.c contains functions to return the proper context from
the struct for a given protocol (and initialize it if needed), and to
cleanup a struct by releasing the crypto contexts.
Previously, the makefile created dependency files in a separate, first
pass. In particular, include-ing the dependency files would cause
make to attempt to rebuild those files using the dependency-generation
rules in the makefile. Unfortunately, this approach required obtuse
rules and silently delayed the start of the build process (by quite a
bit on a clean tree without any dependency files). Worse, this
required the dependency files to themselves depend on all of the
headers the source file depended on, which meant that, if a header
file was removed, the depedency file could not be updated because of a
missing dependency (!), which would cause make to silently fail.
This patch eliminates the dependency generation rules and instead
generates dependency files as a side-effect of the regular build rule.
On the first build, we don't need to know the dependencies beforehand;
the object file doesn't exist, so it will be built anyway. On
subsequent builds, if a header file is updated, the dependency rules
generated by the previous build will force a rebuild. If a source
file is updated, the dependency rules may be stale, but it doesn't
matter because the updated source file will force a rebuild.
In the final case above, the stale dependency rules may refer to a
header file that no longer exists but is also no longer needed. In
order to prevent this from breaking the build, we also pass gcc the
-MP option, which generates phony targets for every depended-on header
file, so make won't complain if it can't find them during a later
build.
Previously, the dependency file list was generated before the CLI
sources were added to SRCS, so dependency files weren't generated for
CLI sources. This moves that code to after the CLI sources are added.
- We have to remove the installation of notmuch.1.gz from the top
level Makefile.local.
- Man pages with multiple names are handled by making relative
symlinks in the install-man target.
- update version tests and convenience rules for split man pages
The man page version test still only checks notmuch.1, but the
location is updated.
update-man-versions is longer than the one-line previously in
update-versions mainly because I decided to take the high road and
stick to POSIX sed (thus, no sed -i). The sed regex itself is more
complicated to cope with variations in the headers.
This wraps all of the complex MIME part handling in a single, simple
function that gets part N from *any* MIME object, so traversing a MIME
part tree becomes a two-line for loop. Furthermore, the MIME node
structure provides easy access to envelopes for message parts as well
as cryptographic information.
This code is directly derived from the current show_message_body code
(much of it is identical), but the control relation is inverted:
instead of show_message_body controlling the traversal of the MIME
structure and invoking callbacks, the caller controls the traversal of
the MIME structure.
Aaron Ecay points out in
id:"1324136185-4509-1-git-send-email-aaronecay@gmail.com" that the
mktemp in
debian-snapshot: TMPFILE := $(shell mktemp)
Is being evaluated for every target. As best I can tell, this is
because make is evaluating the right hand side, even though it is not
doing the assignment.
Of course, it isn't quite as nice to edit with the line continuations,
but it is ideomatic make.
Add mechanism for running user defined hooks. Hooks are executables or
symlinks to executables stored under the new notmuch hooks directory,
<database-path>/.notmuch/hooks.
No hooks are introduced here, but adding support for a hook is now a simple
matter of calling the new notmuch_run_hook() function at an appropriate
location with the hook name.
Signed-off-by: Jani Nikula <jani@nikula.org>
As we noticed when Jani kindly converted things to getopt_long, much
of the work in argument parsing in notmuch is due to the the key-value
style arguments like --format=(raw|json|text).
The framework here provides positional arguments, simple switches,
and --key=value style arguments that can take a value being an integer,
a string, or one of a set of keywords.
The tar file of particular package (notmuch in this case) is named
as $(PACKAGE)-$(VERSION).tar.gz. Therefore the best way to remove
previous link to LATEST is to remove all files beginning with
LATEST-$(PACKAGE)- and not relying how $(VERSION) string is constructed.
The notmuchmail/releases page used to have LATEST-notmuch-<version>
to link to the latest notmuch source tarball. This is confusing on
web page and on disk when the file has been downloaded. This change
looks a bit inconsistent with the 'rm' command just executed before.
$(TAR_FILE) is defined (currently) as $(PACKAGE)-$(VERSION).tar.gz;
as long as the prefix stays $(PACKAGE)-$(VERSION) and version begins
with a digit then this line is good in execution point of view.
Use common sed tool instead of dpkg-parsechangelog (which is usually
available on debian systems only) to verify that debian version
information is consistent with version file.
verfy-version-debian, verify-version-python and verify-version-components
checked noneqality of the comparison strings and if got "positive"
answer then made that goal fail. But in case of the test ([ ])
execution failed it never got to the 'then' part of the line (and
the 'if [ ... ] then ... fi ' construct doesn't make the script line
fail in case of problems inside [ ].
This commit inverses the "logic", so that only if the comparison for
equality succeeds the script line will exit with 0 and execution
can continue past the failure case to the next line (executed by another
shell) with '@echo done'
The version from file "version" is propagated to the man page and the
python bindings via sed. Note that the git version is ignored because
of the check for MAKECMDGOALS.
We keep the lib/xutil.c version. As a consequence, also factor out
_internal_error and associated macros. It might be overkill to make a
new file error_util.c for this, but _internal_error does not really
belong in database.cc.
Currently this builds a native package, but since the source package
is throw away, it should not matter too much, except for the extra
warnings from lintian.
The extra +1 is so that if $(VERSION) is the same as the last released
version (for example outside a git repo) then the versions still order
correctly.
Thanks to Sebastian Spaeth breaking out version.py, this can be done
without loading notmuch.py, or using sed. version.py is not (yet)
autogenerated because it seems more important to minimize the
differences between the tagged version and the tarball.
This is a lighter weight version of the release target, intended to
support uploading release candidates to Debian.
As a side effect, filter ~ out of VERSION to make tag names.
This allows, e.g. gitpkg debian/0.x-1 to do the right thing. It also
helps enforce the convention that Debian upload -1 is identical to the
release tarball.
This supports both testing and use by non-upload privileged
users. Along with previous commits in the series, this lets one do a
dry run of the release process and created a tarball, signature file,
and release announcement to inspect before uploading.
The previous setup was dependent on the git-buildpackage configuration
to find the resulting tar file, and consequently a bit fragile.
We use pristine-tar instead to save a checksum-identical copy of the
tar file. This will also faciliate "non-native" debian packages, if
desired.
dput again depends on the local configuration, and mainly is a bit too
brave for me to do automatically.
The reasoning is that we might have some error in the build system
that causes something not to be rebuilt; this would potentially have
the tests run on the wrong version of the code.
The idea is to see if the version we are already releasing exists on
the notmuch website. Using wget allows more people to run this target,
and also allows people with ssh access to run it without access to
their keys.
Our use of GMimeSession was unneeded boilerplate, and we weren't doing
anything with it. This simplifies and clarifies that assumption.
If we want to do anything fancier later, the examples in the gmime
source are a reasonable source to work from in defining a new
GMimeSession derivative.
Since GMimeSession is going away in GMime 2.6, though, i don't
recommend using it.
This is primarily for notmuch-show, although the functionality is
added to show-message. Once signatures are processed a new
part_sigstatus formatter is emitted, and the entire multipart/signed
part is replaced with the contents of the signed part.
At the moment only a json part_sigstatus formatting function is
available. Emacs support to follow.
The original work for this patch was done by
Daniel Kahn Gillmor <dkg@fifthhorseman.net>
whose help with this functionality I greatly appreciate.
Ever since we added support for "notmuch search --output=tags" the
"notmuch search-tags" command has been redundant. The recent addition
of alias support makes it easy to drop the explicit search-tags
command in favor of a simple alias that runs "notmuch search
--output=tags *".
So there's no longer any documentation of the search-tags command, but
existing scripts will not break at all.
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.
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).
