This looks really interesting, source-navigator has not been actively developed for years, source-insighter is windows-only, eclipse etc is just too heavy for code navigator.
however the 0.1 release is done on 2013.5.6 and that is it, not much development was done since then. Also the 'apt-get' list for compiling simply failed (could not find those packages) on debian 8.
while I really like a light-weight source code navigator,this one needs lots of work it seems.
Someone just sent a patch this morning upgrading it to Clang 3.7, which is available in the Ubuntu 15.10 repository, but not earlier. There are also official x64 llvm.org binaries for 14.04 that work.
I don't actually use the program on a daily basis, but I do pull it out on special occasions. Most recently I used it while tracking down https://github.com/atom/electron/issues/3380. It's helpful because Electron/Chromium is big and I'm unfamiliar with the code.
Nice. I've been wanting something like this. I can imagine using this as a starting point to hack something up with as it appears to have examples for all of the bits I was thinking was going to be hardest :)
+1 for RTags. I recently got it working, and have been enjoying actually navigating through C++ code. Plus, it can do things like show you preprocessor output, show all places where a function is called, show all implementations of a virtual function, complete symbols, show byte offsets of fields, etc.
I have been looking for good code navigation in vim and find it weird, that ctags and scope is oftentimes advertised, as it only does index symbol names.
If two different c++ classes use the same identifier for a member and you even fully qualify it in a .cpp definition (e.g. A::Temp and B::Temp), ctags/cscope still just picks the earliest occurrence of Temp.
Using the clang parser is the obvious thing to do (Qt Creator now has a plugin like this). The real downside to the linux command line tools I found (clic, rtags) is, that you need to provide compiler invokations for all .cpp files to the tools. With cmake, this is easy (call it with -DCMAKE_EXPORT_COMPILE_COMMANDS=ON), but with plain make files, this is pain (specially, if you don't want to setup the whole dependencies): if it doesn't compile, you can't parse.
I would love to see a "parse what is possible", because I'd like to learn from source by running "apt-get source ..." and navigating through parts, that I am interested in without trying to compile everything. Best example for source, I don't want to compile is the Android source code (AOSP). Am I missing something?
SourceWeb needs a list of C++ invocations (compile_commands.json), but it ignores compiler errors, so I'm not sure how precise the invocations need to be. If all the C++ source files in a directory were naively listed, the index might still be useful. I've never actually done that, though -- I normally use the sw-btrace tool to build the JSON file.
The indexer comes up with a globally-unique name for each "symbol" it indexes. This turned out to be a hard problem for things like templates and macros. The indexer names static functions by prepending a filename, e.g. "bio_ssl.c/ssl_write". For local variables, it also appends a file offset. With templates/macros, it can determine that a single identifier corresponds to arbitrarily many different symbols, and when you right-click that identifier in the GUI, it attempts to show them all in a popup menu, which fills the entire screen.
23 comments
[ 3.2 ms ] story [ 69.2 ms ] threadhowever the 0.1 release is done on 2013.5.6 and that is it, not much development was done since then. Also the 'apt-get' list for compiling simply failed (could not find those packages) on debian 8.
while I really like a light-weight source code navigator,this one needs lots of work it seems.
I don't actually use the program on a daily basis, but I do pull it out on special occasions. Most recently I used it while tracking down https://github.com/atom/electron/issues/3380. It's helpful because Electron/Chromium is big and I'm unfamiliar with the code.
All in all this is not as feature complete as source navigator, which is old but works for me better still.
Hopefully it'll mean I can forget about doxygen.
http://code.woboq.org/llvm/clang/include/clang/AST/ASTContex...
https://code.woboq.org/
https://woboq.com/codebrowser.html
https://dxr.mozilla.org/mozilla-central/source/
https://github.com/mozilla/dxr
http://sourcenav.sourceforge.net/
It uses Clang for C/C++/Objective-C/Objective-C++ and exposes itself as a server usable from vim, emacs, sublime ...
If two different c++ classes use the same identifier for a member and you even fully qualify it in a .cpp definition (e.g. A::Temp and B::Temp), ctags/cscope still just picks the earliest occurrence of Temp.
Using the clang parser is the obvious thing to do (Qt Creator now has a plugin like this). The real downside to the linux command line tools I found (clic, rtags) is, that you need to provide compiler invokations for all .cpp files to the tools. With cmake, this is easy (call it with -DCMAKE_EXPORT_COMPILE_COMMANDS=ON), but with plain make files, this is pain (specially, if you don't want to setup the whole dependencies): if it doesn't compile, you can't parse.
I would love to see a "parse what is possible", because I'd like to learn from source by running "apt-get source ..." and navigating through parts, that I am interested in without trying to compile everything. Best example for source, I don't want to compile is the Android source code (AOSP). Am I missing something?
The indexer comes up with a globally-unique name for each "symbol" it indexes. This turned out to be a hard problem for things like templates and macros. The indexer names static functions by prepending a filename, e.g. "bio_ssl.c/ssl_write". For local variables, it also appends a file offset. With templates/macros, it can determine that a single identifier corresponds to arbitrarily many different symbols, and when you right-click that identifier in the GUI, it attempts to show them all in a popup menu, which fills the entire screen.
I have the same problem with CastXML. It's clang-based too. It can't parse my project because of few C++17 "auto" functions.
I'm looking for a GCC-based solution for now.
Its FPS is so fast I knew there was some magic going on behind the scenes, so I poked it.
Turns out there are a bunch of JSON arrays that cross-references x,y coordinates with PNG files, and a tiny player to "render" these in realtime.
The tidbits are right there in the element inspector.
The screencasting tool from the same author:
https://github.com/rprichard/x11-canvas-screencast