CodeLite IDE

Greetings!

I'm using v2.5.2.4031 build of codelite on ubuntu 9.10, which works great. I was wondering if there's a way to browse wxWidgets scource code from within my workspace? My project uses wxWidgets, and autocomplete etc. work just fine without me having to do anything for it. I can right-click on a wxWidgets class name from within my code and choose "Go to Declaration", and land up in the corresponding wxWidgets header file. What I want is to select member functions in wxWidgets classes and go to their implementation (.cpp) file, like I can do for my own code.

I didn't build wxWidgets myself but downloaded headers/libs etc using Synaptic Package Manager. Couldn't find the sources in Synaptic's lists, so downloaded and unpacked them in /usr/share/src.

I remember being able to do this in Visual Studio for wxWidgets by including the .bsc (or some such) file somewhere. I can build wxWidgets myself if that would (somehow, using some tools) make this possible?

Regards,
Saurav.

codelite's code completion parses a file only if it is included by one of the workspace files.

An example:
To make codelite to parse 'wx/button.h' you must include it at least once in your source files otherwise codelite will *not* parse this file (even though it knows where it located)

So, finding the implementation of wxWidgets source file is not possible (since there is no file in your workspace which includes the wxWidgets *.cpp files)
As a workaround, you could do this:

- create another project in your workspace (the type of the project does not really matter, since you don't need to build it)
- right click the new project and select 'import files from a directory' and select the path to the wxWidgets source files
- check all the directories you wish to import (including the root directory) and click OK

Eran

Thanks. That seems to work pretty well!

Regards,
Saurav.

What if a file is indirectly included ?

Should codelite provide completion for the file then ?

I've been having trouble with the python c-api, I do include Python.h which in turn includes the rest, but it doesn't always work. I get completion for some symbols, but not for all.

I did add the path for Python's headers to my workspace (/usr/include/python2.6).

Thanks,
Nox

If not all the symbols are shown, then there is probably a problem of parsing the pre-processors ("defines") in that header file.
codelite can handle many of the defines by simply instructing it to ignore them.

Can you specify an example of method that should appear and does not? and also, which file should I include for that method?

Eran

Sure can.

There's one (maybe more) example in abstract.h, which is included in the python2.6-dev package (using ubuntu, but anyway python-dev should be pretty much the same). One function I remember is PyObject_CallMethodObjArgs.

Nox

Ok, let me start by providing some background of how codelite parsing is working:

codelite uses codelite_indexer to parse files. codelite_indexer is an *extended* version of ctags which runs as a daemon and communicates with codelite over UNIX domain socket OR Named pipe (on Windows). The indexer job is parse files, however since it it based on ctags, its pre processing capabilities are very limited.

One of the extended functionalities that I added to codelite_indexer is to accept a replacement table to manipulate the input file (in memory ofc) so the parser wont get confused when it tries to parse it, a good example for such replacements is: This entry tells codelite_indexer to replace '_GLIBCXX_BEGIN_NESTED_NAMESPACE(std, _GLIBCXX_STD)' with the string 'namespace std{' , now this is done before the actual parsingparsing starts so the parser actually only sees the expanded code (without the ugly macros)

In the file that you complained, (abstract.h) I noticed that all Python API are using this naming convention: Now the macro 'PyAPI_FUNC' breaks the parsing and this is why codelite_indexer did not report this method (or any other method with similar signature)

Obviously, the current token replacement *can* fix this by adding this line: However, it is a tedious job to search in the code for all of the other occurrences of PyAPI_FUNC and add them in all different variations (PyAPI_FUNC(int), PyAPI_FUNC(PyObject* ) etc.)

The solution I came up with is to add new regex find/replace mechanism to the token replacement table.

So by adding this entry to the tokens replacement table: it will fix all occurrences of PyAPI_FUNC in the code (when parsing such signatures)

Let me explain what I wrote above (it might seem gibberish to some people ):
re: these 3 characters tells codelite that this entry uses a regular expression so a Regex search should be used
PyAPI_FUNC\(([0-9a-zA-Z_ \*:&]*)\) this is the regular expression (note that I enclosed the type (e.g. void*) with a parenthesis to form a regular expression sub-match group
\1 this is the 'replace with' entry. \1 in regular expressions means "the first sub-match group", in our case: the text enclosed within the parenthesis of PyAPI_FUNC

The above is committed into SVN trunk and was tested successfully.
If you have further questions, please ask
Eran

Awesome, thanks for the clear explanations!

This must happen with a lot of different libraries, right? I mean python is surely not the first project out there to encapsulate function headers for different compilation types...

How much of a hassle would it be to read preprocessor statements and interpret them? Enough of a hassle to justify those workarounds I guess


However, I just updated from the svn and recompiled (make clean, make, make install) and it still doesn't seem to be parsing properly... I did a full retag of my workspace and nothing still. You say it worked on your setup? I'm on Ubuntu 10.04 x64 if that makes any difference.

Nox

I am on Linux 64 bit as well (9.10) and it is working for me.
Paste here the content of your replacement table so I can compare it with mine

Eran

I don't really know -where- it's supposed to be located...

I did find something that looks to be it in ./CodeLite/tags_option_data.cpp, but there is no line containing the PyAPI thing.