[ekoczwara]

I've checked that option couple months ago. If I remember correctly: rtags was slow, incomplete (you need extra packages for example to follow header files/auto complete header files), with more complicated project you end up with .dir-locals.el, it had problems with switching between desktop/embedded (yocto) builds, overall complicated setup. So many issues with rtags that I didn't even bother to check how it works on windows. I have experience with QtCreator and I would like to reproduce this in Emacs. You open CMakeLists.txt and everything just works.

[dman]

Were there cases where rtags was not finding headers from your compilation database?

[ekoczwara]

So I've played with this some more. I've cleaned up everything, sourced environment-setup from my sdk, configured project with cmake, and now rtags-find-symbol-at-point can't find <iostream> (which is somewhere under /opt/etos/1.2/sysroots), rdm complains 'handleInclude failed (nil) ...' (https://pastebin.com/u39EGzdX).

As 'Disclaimer' in https://github.com/Andersbakken/rtags/blob/master/README.org says: 'RTags is still under development and is not the most stable piece of software you’ll ever find.'. Bugtracker on github has 123 opened issues.

Do you consider RTags as serious option?

[ekoczwara]

I've tried to setup rtags once again to provide detailed info, but I get:

"RTags protocol version mismatch. This is usually caused by getting rtags.el from melpa and installing a new rtags build that modified the protocol. They need to be in sync."

Anyway, I remember that I had negative experience with rtags.

[ekoczwara]

Ok, I've got it running. So the problem is: rtags-find-symbol-at-point opens wrong header files. I'm using custom sdk for embedded target generated by yocto. I need to be able to switch back and forth between desktop and embedded targets. Is this use case supported by rtags?

[dman]

I never had to do that, so don't know if its an issue. I suspect it might not be smart enough to invalidate cache when you switch toolchains.