2009-10-20 07:24:28 +02:00
|
|
|
PROGS=notmuch
|
2009-10-13 16:50:04 +02:00
|
|
|
|
2009-10-25 23:55:23 +01:00
|
|
|
CXXWARNINGS_FLAGS=-Wall -Wextra -Wwrite-strings
|
2009-10-25 23:39:53 +01:00
|
|
|
CWARNINGS_FLAGS=$(CXXWARNINGS_FLAGS)
|
2009-10-25 23:19:36 +01:00
|
|
|
|
|
|
|
CDEPENDS_FLAGS=`pkg-config --cflags glib-2.0 talloc`
|
|
|
|
CXXDEPENDS_FLAGS=`pkg-config --cflags glib-2.0 talloc` `xapian-config --cxxflags`
|
|
|
|
|
|
|
|
MYCFLAGS=$(CWARNINGS_FLAGS) -O0 -g $(CDEPENDS_FLAGS)
|
|
|
|
MYCXXFLAGS=$(CXXWARNINGS_FLAGS) -O0 -g $(CXXDEPENDS_FLAGS)
|
notmuch: Start actually adding messages to the index.
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.
2009-10-19 05:56:30 +02:00
|
|
|
|
2009-10-21 06:03:30 +02:00
|
|
|
MYLDFLAGS=`pkg-config --libs glib-2.0 talloc` `xapian-config --libs`
|
2009-10-13 00:50:02 +02:00
|
|
|
|
2009-10-23 00:31:56 +02:00
|
|
|
MODULES= \
|
|
|
|
notmuch.o \
|
|
|
|
database.o \
|
|
|
|
date.o \
|
|
|
|
message.o \
|
|
|
|
message-file.o \
|
|
|
|
query.o \
|
|
|
|
sha1.o \
|
|
|
|
libsha1.o \
|
|
|
|
xutil.o
|
|
|
|
|
2009-10-13 00:50:02 +02:00
|
|
|
all: $(PROGS)
|
|
|
|
|
notmuch: Start actually adding messages to the index.
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.
2009-10-19 05:56:30 +02:00
|
|
|
%.o: %.cc
|
2009-10-25 06:18:20 +01:00
|
|
|
$(CXX) -c $(CFLAGS) $(CXXFLAGS) $(MYCXXFLAGS) $< -o $@
|
notmuch: Start actually adding messages to the index.
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.
2009-10-19 05:56:30 +02:00
|
|
|
|
|
|
|
%.o: %.c
|
2009-10-21 00:08:03 +02:00
|
|
|
$(CC) -c $(CFLAGS) $(MYCFLAGS) $< -o $@
|
notmuch: Start actually adding messages to the index.
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.
2009-10-19 05:56:30 +02:00
|
|
|
|
2009-10-23 00:31:56 +02:00
|
|
|
notmuch: $(MODULES)
|
notmuch: Start actually adding messages to the index.
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.
2009-10-19 05:56:30 +02:00
|
|
|
$(CC) $(MYLDFLAGS) $^ -o $@
|
2009-10-17 17:26:58 +02:00
|
|
|
|
2009-10-21 00:08:03 +02:00
|
|
|
Makefile.dep: *.c *.cc
|
2009-10-25 23:19:36 +01:00
|
|
|
$(CC) -M $(CPPFLAGS) $(CDEPENDS_FLAGS) $^ > $@
|
2009-10-21 00:08:03 +02:00
|
|
|
-include Makefile.dep
|
|
|
|
|
2009-10-13 00:50:02 +02:00
|
|
|
clean:
|
2009-10-21 00:08:03 +02:00
|
|
|
rm -f $(PROGS) *.o Makefile.dep
|