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