Code Completion Help - CentOS 7

[jarvis]

Hi all,

I'm new to CodeLite and so far it seems to work well for my project, with the exception of code completion (which of course impacts things such as go to implementation/declaration etc.). I am not using an officially built distribution and built it myself, and I'm wondering if that may be part of the problem. I am running a CentOS 7 x64 machine. A number of dependencies I was able to resolve via yum. The only dependency I was missing was wxWidgets 3.0.2. I downloaded this myself and compiled/installed without issue. I was then able to compile/install CodeLite without any problems, and I left all of the CMake options at their defaults. I'm using the default compiler on the system, gcc 4.8.2. There were no compilation errors.

I went into Settings > Code Completion and setup all my include paths appropriately underneath CTags (standard C & C++ include directories, 3rd party libraries like Poco/OpenSSL, and all directories that make up the projects/workspace). It doesn't seem to work for any of the areas I just mentioned. I've gone to Workspace > Retag Workspace (Full) which takes about 10 seconds and appears to go through and reparse the workspace. I end up with a 3 MB <solution>.tags file in the .codelite directory, so it looks like it is writing something out.

Based on my understanding, CodeLite uses a modifed version of CTags that ends up in codelite_indexer. This executable is in my /usr/bin directory along with all the other codelite executables, but I've never seen it running. Is this supposed to run as a background process/daemon? Are there additional install steps needed to set this up when compiling the code yourself? Note that I have tried running this myself (after setting appropriate LD_LIBRARY_PATH) giving the PID of the running IDE instance for the string as well as the --pid option and it looks like it went into a running state, but nothing after that and no change in the IDE.

I have tried enabling clang, which sorta kinda sometimes work (using the same include paths here so I believe they are correct). But there is a lot of latency when using it and it just sometimes doesn't appear to work, and then magically does on the same object. It would be great if CTags was working so I could avoid using this.

It's really frustrating that this piece doesn't work. Everything else appears to be working properly (building, debugging) and I like the IDE otherwise.

Minor suggestion: Setting active projects and storing that in the <solution>.workspace file always gives the appearance that the file has changed (which it has) when checked into source control and sharing among other users. It would make sense to move this into a user file as opposed to the main workspace file.

Thanks in advance for any additional help.

UPDATE: I think the indexer process not starting is the issue. Any tips on how this usually gets started when CodeLite starts? I installed a prepackaged deb package on a test machine and every time I start the IDE the indexer process starts as well. Code completion (using standard c/c++ libraries) works as I would expect. So what's the trick to starting the indexer?

UPDATE2: After starting the IDE, I'm manually starting the indexer like the following. When I choose to retag the workspace, the indexer is throwing an error and exiting. So perhaps the IDE is starting the process, but it is encountering this error and exiting when loading the workspace. Any idea what file it is referring to? I think I'm getting closer...

[dev@system bin]$ export LD_LIBRARY_PATH=/usr/local/lib
[dev@system bin]$ ps -ef | grep " codelite"
dev 20463 65367 72 19:57 ? 00:01:01 codelite
dev 42784 519 0 19:58 pts/0 00:00:00 grep --color=auto codelite
[dev@system bin]$ ./codelite_indexer 20463 --pid
INFO: parent PID is set on 20463
INFO: codelite_indexer started
INFO: listening on /tmp/codelite_indexer.20463.sock
INFO: WorkerThread: Started
ctags: cannot open tag file : Permission denied
[dev@system bin]$

UPDATE 3: I knew there had to be a log! I just looked in the codelite-stdout-stderr.log file and there are a lot of these message repeated in sections:
Failed to connect to indexer ID 20463!
Failed to connect to indexer ID 20463!
ERROR: Connection refused
ERROR: Connection refused
ERROR: Permission denied
ERROR: Permission denied

I checked my /tmp dir, files are there but are zero bytes (not sure if that is normal honestly). Permissions look OK to me (note I've tried running everything under my normal user account, as well as the root user which is why some are different:

xr-x 1 dev dev 0 Mar 4 19:45 codelite_indexer.65367.sock
srwxr-xr-x 1 root root 0 Mar 4 12:54 codelite_indexer.8221.sock
srwxrwxr-x 1 dev dev 0 Mar 4 12:30 codelite_indexer.codelite.sock
srwxrwxr-x 1 dev dev 0 Mar 4 12:45 codelite_indexer.--help.sock

Connection wise there are no firewalls running on my system right now while I troubleshoot. File permissions seem to be OK, but there are probably others I am unaware of. That's probably it for tonight, I'll be picking this back up again tomorrow. Still looking for some help here!

[eranif]

This executable is in my /usr/bin directory along with all the other codelite executables, but I've never seen it running. Is this supposed to run as a background process/daemon? Are there additional install steps needed to set this up when compiling the code yourself

Yes, codelite_indexer runs as background process. No additional steps are needed, just make install and thats it

I went into Settings > Code Completion and setup all my include paths appropriately underneath CTags (standard C & C++ include directories, 3rd party libraries like Poco/OpenSSL

The default C++ headers path should be set there by default, if not click on the "Suggest paths". There is no need to manually enter the rest of the include paths, as these are taken from your project settings

I end up with a 3 MB <solution>.tags

This is a very small .tags database, usually you should have around 30-100 mb of data

UPDATE: I think the indexer process not starting is the issue. Any tips on how this usually gets started when CodeLite starts?

CodeLIte starts the indexer automatically, there are no manual steps that should be taken

I checked my /tmp dir, files are there but are zero bytes (not sure if that is normal honestly)

Its normal. The "s" at the start of the file permissions means: a UNIX socket file

Connection wise there are no firewalls running on my system right now while I troubleshoot

The communication between codelite and the indexer is done over UNIX domain socket, so firewalls don't really interfere with codelite <-> codelite_indexer communication

I don't really understand why codelite_indexer is not starting properly for you, I guess you will have to debug it..

Eran

[jarvis]

Thanks for your response. I spent a little more time looking at this today. What I found was that Option.tagFileName was being set to "tags" and when openTagFile (in entry.c) was called, it was trying to open this file with "w" permissions. At the time, the current working directory is /usr/bin (where codelite_indexer resides) which by default the bin directory only has 555 permissions set.

So I rebuilt codelite_indexer. In options.c, I added the following define, and then modified setDefaultTagFileName():

Code: Select all

#define HOME_FILE "/home/dev/tags"

extern void setDefaultTagFileName (void)
{
	if (Option.tagFileName != NULL)
		Option.tagFileName = stringCopy (HOME_FILE);
	else if (Option.etags)
		Option.tagFileName = stringCopy (ETAGS_FILE);
	else
		Option.tagFileName = stringCopy (CTAGS_FILE);
}

I copied the new executable into my /usr/bin directory. I started up CodeLite - nothing. Process didn't start. So I opened my workspace, manually started the rebuilt codelite_indexer with $PID --pid, and retagged my workspace. It took a lot longer to parse, and the codelite_indexer process didn't go down. Checked it out, code completion worked flawlessly! <solution>.tag file was much larger than just 3 MBs as well as you pointed out.

Still have a problem of the process not starting on its own (or as I suspect, trying to start and encountering an error). I'm not sure if there is some environment variable somewhere I need to set that would help specify working directories or not. CTags on its own has options but the codelite_indexer process doesn't expose these as additional arguments. I'm not sure why only on CentOS 7 systems this appears to be a problem, it doesn't look like other distros try to write this file to /usr/bin.

Does any of this ring any bells to anyone? If not, I guess I'll keep working at it. I'm going to have lie about accomplishing things at work today it looks like...

[jarvis]

Well, looks like the problem starting the indexer when starting the IDE is a different problem. It doesn't appear to be related to the indexer itself. I'm going to have to dig into how the IDE tries to start the indexer it looks like. I modified the indexer as soon as main is hit so that it creates a file and logs a message. The file is never created when I launch the IDE, so it looks like it is having a problem even starting the indexer. The file gets created just fine if I manually start the indexer process.

[jarvis]

Finally, I was able to figure this out. Eventually I found my way to ProcessReaderThread::Entry(). It was in here that I was able to see that the indexer process was attempting to start, had a process Id, and the returned communication buffer held an error message indicating it couldn't find a library file before the process terminated. The library it was looking for was related to wxWidgets, which I found in /usr/local/lib. This happens to be where all the libwx_gtk2u*.so files were installed after I built wxWidgets and did a "make install". Once I understood this, I didn't have to make any code changes to get it to work properly. All I needed to do was:

cd /etc/ld.so.conf.d
touch codelite.conf
echo "/usr/local/lib" >> codelite.conf
ldconfig

And problem solved! I would like to thank myself for solving this problem.

With that out of the way, perhaps I will move on to moving the selected project/configuration out of the main workspace file and into a user file.