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).
