I'll post here the interesting info from
http://vcfbuilder.org/?q=node/143 since it requieres registration:
(The replies are from ddiego)
Something very simmilar to your purpose have been done here: http://forums.codeblocks.org/index.php?topic=1889.0
You really want to read that thread.
However, I didn't have it clear: you will be discarding ANTLR at all, and only using CTags?
Or will use ANTLR to generate the database?
Interesting thread. I still see the need for only 2 "parsers".
The ctags parser is used to create the persistent DB which will exist in various places just like it Visual Studio does with it's .ncb files. The question becomes how often these db files become updated. For system include directories this would be a one time cost, the db is made once, and then not messed with unless the system includes dir changes or the system include files changes.
The db for the project would be more volatile, that would have to be changed more often, but given the speed of ctags and sqlite I don't see this as a problem.
The difference between the DB data and the parser data, is that the DB data would be more sparse. But the result of using either one would be the creation of an AST that is a graph of CodeNode instances that can be traversed. So if you parse a single file with the ANTLR based C++ parser, or request some data from the ctags based DB, both will return this information as a collection of CodeNode's.
...
I am (I'm already coding this right now) using both. The idea is to use ctags to create a DB that has a broad overview of the various AST elements, but use ANTLR to provide an exact view of a specific file/resource.
...
In addition to my earlier comments here are some thoughts on where I'd like to see this whole thing going:
Currently, relying we are relying soley on the C++ parser to handle ALL of the parsing chores. To parse a single file in "real time" (about as fast as you can type), it works OK, but to potentially have to have it parseing thousands of files to keep track of all the possible headers in your project, plus system (and other third party headers) files seems unwieldy - it just won't handle this fast enough.
So this got me thinking about how all of this (the parser and the CodeStore "engine") should work. After taking a glance at how Visual Studio seems to do things I've come to some conclusions:
* First, an simplify things by creating a database of all the core elements that we need to display in our class AST. This set of elements is a subset of the entire AST for any given file. We care about things like function declarations, function arguments, templates, template arguments, class declarations, namespace declarations. Putting these into a database makes it easy to search, and provides more potential flexibility for search types.
* If we have a database of this data, then it makes sense to support more than one. There would be one db per project, and then one (or more) "global" db's for system headers (like the C runtime, or the C++ STL). The global db's would only have to be generated once, since these won't change often (if at all).
* We would need a schema for the db, a table that has the following columns:
o id INTEGER PRIMARY KEY
o name TEXT
o filename TEXT
o line INTEGER,
o kind INTEGER,
o language INTEGER,
o access INTEGER
o inheritance TEXT,
o parent INTEGER,
o signature TEXT
This schema would allow for generating a hierarchical display if neccesary
* To generate these databases, we don't need the full fledged support of the C++ parser, since we need only a limited number of AST nodes, at this level. So what what I'm thinking is to use ctags to generate the initial db info, then use SQLite3.2 to create/store the ctags data into a db. This would accomplish most of what we need, then use the parser for those cases where the entire AST is needed. Using ctags, and SQLite, I can create a DB representation of the entire VC98/Includes directory from scratch in about 1 minute or less (that's about 726,773 lines of code scanned). And this would only have to be done once.
All of the above would be done transparently by the CodeStore engine. SQLite source would become incorporated, and ctags would be used as an exe (we can't use it directly as a library due to GPL issues).
----
You can check out the project by doing:
svn co https://svn.sourceforge.net/svnroot/classdom classdom
