For your tool to read symbols from the .api files, you should be able to
just run the tool. Check it's arguments to see what sort of output
options it has. That way you don't have to compile anything. Emacs can
run the tool, get the output text, and parse that. Often such tools
have an option for output that is easy to parse.
Once you have that, then the rest is about filling in some functionality
to interface it with CEDET.
I have attached the FSF template for assigning copyright for
contributions to Emacs. If you choose to fill it out, you need to send
it to the email address IN THE FILE, not to this mailing list.
On 08/02/2013 11:04 AM, Kenneth Miller wrote:
> 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 <eric@...>
> *To:* Kenneth Miller <kennethadammiller@...>
> *Cc:* "cedet-devel@..."
> *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.
> Good Luck
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> Cedet-devel mailing list