Commits 9db2145272 ("lib/gen-version-script.h: add getline and
getdelim to notmuch.sym if needed") and 3242e29e57 ("build: add
canonicalize_file_name to symbols exported from libnotmuch.so")
started exporting compat functions from libnotmuch so that the cli
could use them. But we shouldn't export such functions from the
library. They are not part of our ABI. Instead, the cli should include
its own copies of the compat functions.
The tar content `git archive` creates (reproducibly) have owner and
group set to 'root'. (GNU) tar writes user ids to the added file
`version` by default. The contents of tar archive looks better and
more consistent when owner and group in all files are the same.
While at it, split this long command line to multiple lines.
Apparently some systems (MacOS?) have a system library called libutil
and the name conflict causes problems. Since this library is quite
notmuch specific, rename it to something less generic.
I noticed when trying to use VERSION (and derived variables) in a
subdirectory that the top level Makefile.local needed to be included
first. But according to c10085c77b it
actually needs to be last. To break this conflict, move the variables
definitions into a new Makefile.global.
Apparently pre 5.1 gcc defaulted to gnu89, but we decided it was ok to
use some c99 features.
'-std=c99' by itself is not enough for notmuch to compile.
'-std=gnu99' seems to work with clang and gcc, so I'm not convinced
configuration support is needed.
With this GNU Make construct one shell invocation can be skipped
and code looks shorter (narrower). This would now match to .git
being other file type than regular file or directory (or symlink
to those), but that is not a use case anyone should expect users
to do.
Many of the external links found in the notmuch source can be resolved
using https instead of http. This changeset addresses as many as i
could find, without touching the e-mail corpus or expected outputs
found in tests.
this is a minor security hole, but no worse than what we had before. In
particular the worst that happens is someone prevents us from making a
release. Which is hardly worth the trouble of jacking the URL.
Because ruby generates a Makefile, we have to use recursive make.
Because mkmf.rb hardcodes the name Makefile, put our Makefile{.local}
in the parent directory.
Failing to update this string in globals.py causes failures when the
SONAME changes. In order to hopefully reduce the number of such
errors, automate the process of setting the SONAME in the python
bindings.
So that $(VERSION) and version.stamp uses the git-describe -based
version data instead of the content of `version' file.
For consistency also the git commands in Makefile[.local] target
`verify-no-dirty-code' uses the git --git-dir=$srcdir/.git ...
commands (inside ifeq($(IS_GIT),yes)). Attempting to make this
target outside of the tree will fail in any case.
It turns out to be inconvenient to delete the downloaded datafiles with
distclean, so I propose a new target which does that instead.
The closest conventional target is 'maintainer-clean'; the difference
here is that having the original source tarball is not enough to
reconstruct these files.
In my system `pkg-config --libs talloc` returns
'Wl,-rpath,/usr/lib -ltalloc' (probably wrongly) which causes the final
LDFLAGS to be something like '-Wl,-rpath,/usr/lib
-Wl,-rpath,/opt/notmuch/lib', which causes the RUNPATH to be
'/usr/lib:/opt/notmuch/lib', so basically defeating the whole purpose of
RUNPATH.
I noticed this when my /opt/notmuch/bin/notmuch (0.17) started updating
the database after I updated the system (which updated the system's
notmuch). This shouldn't happen.
Let's move the RUNPATH flags before other external flags have a chance of
screwing the build.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
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.
