[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: Full Text Indexing for KMAIL: SUBMISSION
From:       Luís_Pedro_Coelho <luis () luispedro ! org>
Date:       2005-05-28 14:47:18
Message-ID: 200505281547.18897.luis () luispedro ! org
[Download RAW message or body]

On Saturday 28 May 2005 12:56, Ingo Klöcker wrote:
> Yeah, I'm also looking forward to seeing it in action. But before you
> commit can you please briefly describe what dependencies we get?

Kmail dependencies:
	- index library headers (compile time)
	- index library .so (link & run time)

To compile the indexing library itself you need boost (http://www.boost.org), 
but this is a header file only dependency and I include a copy of the 
necessary header files in my indexlib distribution (bc boost is (1) not 
widely included in linux distros and (2) boost is not very source-compatible 
between versions), so the dependency isn't really felt. Also you need scons 
to compile, but again, my package will try to detect scons and if it doesn't 
find it, it will download a copy and run that (without installing it). It 
does need python installed though, but that's pretty standard and no special 
version is needed. I would have no problems in converting to 
autoconf/automake except that I don't really know how to write autoconf.

So, in fact, just downloading the tarball and typing "./configure; make ; make 
install" should work fine without more work than answering "Y" to the "Do you 
want to automatically download scons?" question (I include a fake Makefile 
which forwards to scons like the current unsermake Makefiles forward to 
unsermake).

> Google-like behavior, i.e. full text searches. Of course, this implies
> that we have to change the way the search phrase is interpreted, i.e.
> we have to interpret it as list of words that should be contained, but
> not as phrase that needs to match exactly. (IIRC the full text search
> already does this?)

My implementation mimics google in that you can use quotes to search for the 
exact phrase (case-insensitive and without diacritics).

> So you really want to release the library as external package? 

I don't really know whether anyone would like to use this somewhere else, but 
I don't really think it belongs in KDE since it is not KDE/Qt based at all. 
One of the goals was performance and I believe that the low level approach I 
took paid off so all the structures are hand-written (especially in order to 
control the disk layout).

OTOH, keeping the library close to kmail which is the only place which uses it 
right now will insure that there is no need to update an external package if 
a new version comes out.

> That's why I propose to at least put a copy into kdesupport. At least,
> as long as the library isn't included in the majority of distributions.

Sure.

> > > Could anyone help me
> > > out here? I would need help in figuring the best way to make the
> > > library "findable"
>
> "findable"? You mean the source?

I meant a way to have configure find out what compile/link flags it needs to 
compile kmail. It needs to find out where the files were installed.

> Sorry, I don't know a good example. You could look at
> kdepim/kpilot/configure.in.* for a complicated example.

I will.

thanks,
-- 
luispedro
http://blog.luispedro.org/
http://luispedro.org/
_______________________________________________
KMail developers mailing list
KMail-devel@kde.org
https://mail.kde.org/mailman/listinfo/kmail-devel

[prev in list] [next in list] [prev in thread] [next in thread]