4
Things have started to stabilize a bit, so I will attempt to explain
5
the internals of the new LXR.
7
The goal of this new version is to support version control systems.
8
The old LXR did version control by maintaining separate source trees
9
and separate identifier databases. While this seemed to work fine it
12
We realized early that db-file databases were too weak for our
13
purpose, a real relational database would enable us to do much more
14
without the speed penalties of the db-files. We have therefore
15
abstracted the database that contains information about the
16
identifiers into the module LXR::Index. The LXR::Index::DBI module
17
uses the perl DBI interface to a relational database (we used postgres
18
for most of our development), while LXR::Index::DB tries to accomplish
19
the same by using db-files. This makes it possible for those with
20
large source-trees to use DBI and those who do not want to install a
21
RDBMS can stay with the db-files.
23
The old lxr had to store a complete source-tree for each version you
24
wanted to index. When the number of versions were relatively low this
25
worked just fine, but if you wanted to index the whole linux kernel
26
history the space requirement would be very large. It would therefore
27
be nice to be able to do the indexing on a CVS tree. The LXR::Files
28
backend abstacts the underlying file storage mechanism from the rest
29
of the system. (If you think we are thinking too much object
30
orientation and abstracting too much remember that we are both brought
31
up at the university where object orientation was invented :-). The
32
LXR::Files::Plain uses the old method were each version is stored in a
33
separate repository, while LXR::Files::CVS fetches the files from a
34
CVS repository. It should be possible to add support for other forms
35
of version control in the future.
37
Another design-goal for this new version was to support multiple
38
languages. Our old index generator was very c-specific and its
39
internals were really messy. We decided to get rid of that code and
40
are now using external index generators. Exuberant c-tags is very
41
good, and finds as many indentifiers as our old genxref did. The new
42
genxref uses the LXR::Tagger module. This module dispatches each
43
source file to the correct index generator. The markup of the code
44
displayed to the user is handled by the LXR::Lang module. This means
45
that all that have to be done to add support for a new language is to
46
write a LXR::Lang::Foo and a LXR::Tagger::Foo module.
added
removed
HACKING
