debian/notmuch
1
0
Fork 0
mirror of https://git.notmuchmail.org/git/notmuch synced 2024-11-22 19:08:09 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
notmuch/Makefile

27 lines
777 B
Makefile
Raw Normal View History

Start a new top-level executable: notmuch. Of course, there's not much that this program does yet. It's got some structure for some sub-commands that don't do anything. And it has a main command that prints some explanatory text and then counts all the regular files in your mail archive.
2009-10-17 17:26:58 +02:00
PROGS=notmuch notmuch-index-message xapian-dump
Add the beginnings of a xapian-dump program. This will (when it is finished) make a much more reliable way to ensure that notmuch's sync program behaves identically to sup-sync. It doesn't actually do anything yet.
2009-10-13 16:50:04 +02:00
notmuch: Switch from gmime to custom, ad-hoc parsing of headers. Since we're currently just trying to stitch together In-Reply-To and References headers we don't need that much sophistication. It's when we later add full-text searching that GMime will be useful. So for now, even though my own code here is surely very buggy compared to GMime it's also a lot faster. And speed is what we're after for the initial index creation.
2009-10-19 21:54:40 +02:00
MYCFLAGS=-Wall -O0 -g `pkg-config --cflags glib-2.0`
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
MYCXXFLAGS=$(MYCFLAGS) `xapian-config --cxxflags`
notmuch: Switch from gmime to custom, ad-hoc parsing of headers. Since we're currently just trying to stitch together In-Reply-To and References headers we don't need that much sophistication. It's when we later add full-text searching that GMime will be useful. So for now, even though my own code here is surely very buggy compared to GMime it's also a lot faster. And speed is what we're after for the initial index creation.
2009-10-19 21:54:40 +02:00
MYLDFLAGS=`pkg-config --libs glib-2.0` `xapian-config --libs`
Initial commit of a test program to form the basis of notmuch. Basically just playing with some simple code using libgmime to parse an email message.
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
$(CXX) -c $(CXXFLAGS) $(MYCXXFLAGS) $^ -o $@
%.o: %.c
$(CC) -c $(CFLAGS) $(MYCFLAGS) $^ -o $@
notmuch: Switch from gmime to custom, ad-hoc parsing of headers. Since we're currently just trying to stitch together In-Reply-To and References headers we don't need that much sophistication. It's when we later add full-text searching that GMime will be useful. So for now, even though my own code here is surely very buggy compared to GMime it's also a lot faster. And speed is what we're after for the initial index creation.
2009-10-19 21:54:40 +02:00
notmuch: notmuch.o database.o message.o xutil.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
$(CC) $(MYLDFLAGS) $^ -o $@
Start a new top-level executable: notmuch. Of course, there's not much that this program does yet. It's got some structure for some sub-commands that don't do anything. And it has a main command that prints some explanatory text and then counts all the regular files in your mail archive.
2009-10-17 17:26:58 +02:00
Rename g_mime_test to notmuch-index-message In preparation for actually creating a Xapian index from the message, (not that we're doing that quite yet).
2009-10-13 22:28:13 +02:00
notmuch-index-message: notmuch-index-message.cc
Start a new top-level executable: notmuch. Of course, there's not much that this program does yet. It's got some structure for some sub-commands that don't do anything. And it has a main command that prints some explanatory text and then counts all the regular files in your mail archive.
2009-10-17 17:26:58 +02:00
$(CXX) $(CXXFLAGS) $(MYCXXFLAGS) notmuch-index-message.cc `pkg-config --cflags --libs gmime-2.4` `xapian-config --cxxflags --libs` -o notmuch-index-message
Add the beginnings of a xapian-dump program. This will (when it is finished) make a much more reliable way to ensure that notmuch's sync program behaves identically to sup-sync. It doesn't actually do anything yet.
2009-10-13 16:50:04 +02:00
xapian-dump: xapian-dump.cc
$(CXX) $(CXXFLAGS) $(MYCXXFLAGS) xapian-dump.cc `xapian-config --libs --cxxflags` -o xapian-dump
Initial commit of a test program to form the basis of notmuch. Basically just playing with some simple code using libgmime to parse an email message.
2009-10-13 00:50:02 +02:00
clean:
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
rm -f $(PROGS) *.o
Reference in a new issue Copy permalink