Wow, I have never received such a serious response that both enlightened the path forward, and that so warmly welcomed me into making contributions to open source. You're a step above, and I appreciate the willingness to take the time and write me the extensive email.
Actually, since I know for a fact that the tool that I'm using implements its own parser for the .api files, (I even found the exact function doing the work) I could simply import that parsing logic,
line for line as a function into semantic. The last thing I need to verify before moving forward is that .api files are indeed generated by SIP. Importing the .api files would be the absolute easiest, because I both know the path forward, and because the file format lends itself to our purposes. I was wondering, since the parser that already exists was implemented in C++, is there any way I could just extract that function into it's own sort of extension module for emacs, and emacs could just call into C++? That would give emacs' semantic some extra dependencies, namely the qt library, but it would be the most rapid way forward.
Otherwise, I would have to port the C++ function line by line, and I'm not adept at elisp (yet).
Which way do you recommend forward (yes, FSF contact is implied :))?
From: Eric M. Ludlam <firstname.lastname@example.org>
To: Kenneth Miller <email@example.com>
Cc: "firstname.lastname@example.org" <email@example.com>
Sent: Thursday, August 1, 2013 7:44 PM
Subject: Re: [CEDET-devel] python extension module trouble
On 08/01/2013 09:55 AM, Kenneth Miller wrote:
> So, I love CEDET and I have a C++ project. Part of this C++ project uses
> some external libraries, and there haven't been any problems with
> getting semantic to pick up those external headers; there's good support
> for it. However, part of this project uses python to help do rapid
> development by scripting the C++ functions between one another. There
> are bindings generated by Riverbank Computing's SIP tool, and python is
> able to import the .so files; the problem with Semantic is that when you
> specify that you want semantic to pick up some external python modules,
> python extension modules get excluded. Semantic doesn't pick up so well
> what is made available by the python extension modules.
> Is there some way that the api files (which I believe are SIP generated)
> can be imported into the semantic auto completion
or semantic syntax
> checker for python? Or could CEDET somehow have a function added so that
> it could pick up a python extension module, and extract what is made
> available from it? (Because I know that I can get help information after
> I import the modules at the level of the python interpreter) Please see
> the stack overflow question below:
CEDET can pull symbol information for your project from different
places, and each requires someone to write some support code.
The first is a parser for the code you are editing. There is already
such a parser so you are set there.
The second is through the 'semanticdb-' interface. When the symbol
lookup system in CEDET used for tag jumping and completion needs to find
a set of matching
symbols, it builds up a search path, and the search
path is made up of semanticdb- databases. Many databases are file
based, so it is a system that caches all the symbols discovered via the
source code search from the parser. That same interface can be
subclassed and the subclass can extract symbols from alternate sources.
The simplest such database you could look at as an example is
semantic/db-el.el, or the Emacs global symbol database. There are
similar databases for using GNU Global and cscope.
A more complex example is semantic/db-javap.el which can read symbols
from Java .jar files which closely mimics what it sounds like you are
trying to do.
The typical way this code is organized is to implement something in
lisp/cedet/cedet-NAME.el whose job is to run an external program, check
the supported version, etc. The second is to add something to
lisp/cedet/semantic/db-NAME.el which subclasses
semanticdb-abstract-table, and them implements several search functions.
The javap version makes a java call, parses the output, stores all the
symbols, and uses standard semantic search routines. The Global
database implements the search functions via calls to global, so the
global command does the searches. You would need to study the program
you have available for extracting the symbols you want to see which
technique to use.
Lastly, if you take on such a cool project and are interested in
contributing back to the CEDET project, you will need to have assigned
your contributions to the FSF. If you want to do that, I can forward
the information that you need to you.