The appended file 'version' has the same timestamp as the files added
by `git archive`.
The original file name and time stamp are no longer saved to the
gzip header in resulting $(PACKAGE)-$(VERSION).tar.gz file.
When build environment is close enough to another, this may
provide mutually reproducible release archive files.
The advantage of having a target as opposed to running cppcheck by
hand
- reuse list of source files
- output errors in a format parsable, e.g. by emacs
- returns exit code 1 on any error, for possibly use in other
targets.
For the moment, leave this as an optional target. If desired, it can
be added to e.g. the release targets in the same way as the test
target.
Using two levels of directory for the stamps is arguably
overengineering, but it doesn't really cost anything, and leaves open
the possibility of putting other kinds of stamp files there.
This only checks "new" source files (w.r.t. their last check). A future target
(cppcheck-all ?) could blow away the stamp files first.
Sometimes using $@ as the target in the quiet build lines can be
confusing. Accept an optional second parameter in the quiet variable
function to specify the target.
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 ]
