| Age | Commit message (Collapse) | Author |
|---|
|
This is closely based on git-remote-nm (in ruby) by Felipe Contreras.
Initially just implement the commands 'capabilities' and 'list'. This
isn't enough to do anything useful but we can run some simple unit tests. Testing
of URL passing will be done after clone (import command) support is
added.
|
|
Python likes to leave behind cache files; noticeable when doing an
in-tree build.
|
|
nmbug and notmuch-git are new build products. Make git ignore them just
like other build products.
Signed-off-by: Michael J Gruber <git@grubix.eu>
|
|
This is generated by configure and should not be committed.
|
|
|
|
|
|
|
|
The current case is docstring.stamp, but it's likely that others will
arise.
|
|
|
|
A leading / in paths in a .gitignore file matches the beginning of the
path, meaning that for patterns without slashes, git will match files
only in the current directory as opposed to in any subdirectory.
Prefix relevant paths with / in .gitignore files, to prevent
accidentally ignoring files in subdirectories and possibly slightly
improve the performance of "git status".
|
|
The dynamic generation of the linker version script for libnotmuch
exports has grown rather complicated.
Reverse the visibility control by hiding symbols by default using
-fvisibility=hidden, and explicitly exporting symbols in notmuch.h
using #pragma GCC visibility. (We could also use __attribute__
((visibility ("default"))) for each exported function, but the pragma
is more convenient.)
The above is not quite enough alone, as it would "leak" a number of
weak symbols from Xapian and C++ standard library. Combine it with a
small static version script that filters out everything except the
notmuch_* symbols that we explicitly exposed, and the C++ RTTI
typeinfo symbols for exception handling.
Finally, as the symbol hiding test can no longer look at the generated
symbol table, switch the test to parse the functions from notmuch.h.
|
|
|
|
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.
|
|
Start a seperate .gitignore for emacs stuff, move .elc rule there.
|
|
|
|
Parallel to ignoring .so for linux.
|
|
The line 'notmuch' in the toplevel .gitignore file is to broad
and matches bindings/python/notmuch making it cumbersome to
git-add files within that directory.
Refine the toplevel file to only match the generated notmuch
executable and add a more specialized .gitignore file to the
python directory.
Signed-off-by: Justus Winter <4winter@informatik.uni-hamburg.de>
|
|
This is a generated file, so will not be under git control.
|
|
Finally, a single button to push to do all the uploading.
|
|
On Bdale Garbee's recommendation I'm switching from gitpkg, (which
constructed a source tree but still required me to go run debuild), to
git-buildpackage. I hadn't originally used git-buildpackage because it
didn't seem to work without a configuration file, (where gitpkg was
fine).
Bdale was kind enough to point me to his fw/altos source at
git.gag.com where I found an example gpb.conf file as well as a target
in debian/rules to automatically update debian/changelog with the new
version number.
|
|
The "make release" target creates this directory, but it's nothing
I'll ever want to add to the git repository.
|
|
|
|
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.
|
|
Signed-off-by: Ingmar Vanhassel <ingmar@exherbo.org>
|
|
Instead of shipping a default version, we now add a rule to automatically
run configure if necessary to create Makefile.config.
|
|
1) Add a separate targets to build and install emacs mode.
2) Don't hardcode the installation directory, instead use emacs'
pkg-config module.
3) Install a byte compiled version of the emacs mode.
4) Install the emacs mode in emacs' site-lisp directory. Put
"(require 'notmuch)" in your .emacs to load it automatically.
5) Ignore byte-compiled emacs files.
Signed-off-by: Jeffrey C. Ollie <jeff@ocjtech.us>
Reviewed-by: Ingmar Vanhassel <ingmar@exherbo.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
|
|
|
|
|
|
|
|
|
|
We recently moved dependencies from a single .depends file to a directory
named .deps with many files, but neglected to update our .gitignore rules.
|
|
Instead of the old name of Makefile.dep. The idea being that the
user really doesn't need to see this by default, (and if debugging
the Makefile, the rules will make the name obvious).
|
|
By pulling content out of notmuch help, and also the messages
printed by "notmuch setup".
|
|
Forgot to add this when I first add dependency checking to the
Makefile.
|
|
These were just little tests while getting comfortable with
GMime and xapian. I'll likely use pieces of these as notmuch
continues, but for now let's not distract anyone looking
at notmuch with these.
And the code will live on in the history if I need to look
at it.
|
|
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
|
|
In preparation for actually creating a Xapian index from the
message, (not that we're doing that quite yet).
|
|
|
