ruben2020 / codequery

A code-understanding, code-browsing or code-search tool. This is a tool to index, then query or search C, C++, Java, Python, Ruby, Go and Javascript source code. It builds upon the databases of cscope and ctags, and provides a nice GUI tool.

Home Page:https://ruben2020.github.io/codequery/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Unreliable operation with C++ code

sdaau opened this issue · comments

commented

Hi,

I just built codequery from git, hoping to analyse some openFrameworks code - unfortunately, it doesn't seem to quite work. This is my system info:

$ uname -a
Linux mypc 4.2.0-42-generic #49~14.04.1-Ubuntu SMP Wed Jun 29 20:22:11 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
$ cscope --version
cscope: version 15.8a
$ ctags --version
Exuberant Ctags 5.9~svn20110310, Copyright (C) 1996-2009 Darren Hiebert

This is how I installed it - basically following https://github.com/ruben2020/codequery/blob/master/doc/INSTALL-LINUX.md, with some changes cause my system is older (and using a build64 folder, since I use the same source folder in both 32-bit and 64-bit Ubuntu):

sudo apt-get install sqlite3 cscope exuberant-ctags
sudo apt-get install libsqlite3-dev qt4-dev-tools
sudo apt-get remove --purge cmake cmake-curses-gui cmake-data # because too old, "CMake Error at CMakeLists.txt:1 (cmake_minimum_required): CMake 3.2.2 or higher is required.  You are running version 2.8.12.2"
wget https://cmake.org/files/v3.9/cmake-3.9.4-Linux-x86_64.sh
bash cmake-3.9.4-Linux-x86_64.sh --prefix=/path/to

cd /path/to/src
git clone https://github.com/ruben2020/codequery.git codequery_git
cd codequery_git
mkdir build64
cd build64
/path/to/cmake-3.9.4-Linux-x86_64/bin/cmake -G "Unix Makefiles" -DBUILD_QT5=OFF ..
sed -i"" 's_../build/_../build64/_' /path/to/src/codequery_git/gui/codequery.qrc
make
sudo apt-get remove --purge libsqlite3-dev qt4-dev-tools && sudo apt-get autoremove --purge
sudo ln -s /media/Data1/src/codequery_git/build64/codequery /usr/bin/
sudo ln -s /media/Data1/src/codequery_git/build64/cqmakedb /usr/bin/
sudo ln -s /media/Data1/src/codequery_git/build64/cqmsearch /usr/bin/

OK, then I went to my openFrameworks dir, which contains library code and some of my apps code; since there are underscores and spaces in some of the pathnames (see https://stackoverflow.com/questions/3196760/how-to-use-cscope-with-paths-that-contain-spaces), I had to do this - have one file with quoted filenames for cscope (else cscope: cannot find file apps/devApps/ofPolyline etc), and another with unquoted for ctags (else ctags: Warning: cannot open source file ""./libs/freetype/include/freetype2/inter... etc):

cd /path/to/src/openFrameworks
find . -iname "*.c"   -fprintf /dev/stdout '"%p"\n' >> cscope.files
find . -iname "*.cpp" -fprintf /dev/stdout '"%p"\n' >> cscope.files
find . -iname "*.cxx" -fprintf /dev/stdout '"%p"\n' >> cscope.files
find . -iname "*.cc " -fprintf /dev/stdout '"%p"\n' >> cscope.files
find . -iname "*.h"   -fprintf /dev/stdout '"%p"\n' >> cscope.files
find . -iname "*.hpp" -fprintf /dev/stdout '"%p"\n' >> cscope.files
find . -iname "*.hxx" -fprintf /dev/stdout '"%p"\n' >> cscope.files
find . -iname "*.hh " -fprintf /dev/stdout '"%p"\n' >> cscope.files
cscope -cb                                                # created 88 MB `cscope.out` file
find . -iname "*.c"    > ./ctags.files
find . -iname "*.cpp" >> ./ctags.files
find . -iname "*.cxx" >> ./ctags.files
find . -iname "*.cc " >> ./ctags.files
find . -iname "*.h"   >> ./ctags.files
find . -iname "*.hpp" >> ./ctags.files
find . -iname "*.hxx" >> ./ctags.files
find . -iname "*.hh " >> ./ctags.files
ctags --fields=+i -n -R -L ./ctags.files                  # created 39MB `tags` file
cqmakedb -s ./myproject.db -c ./cscope.out -t ./tags -p   # created 419MB `myproject.db` file

At the least, this could be a documentation bug, but it's no biggie, since up to this point, all seems to work.

Then I open myproject.db in codequery. Another buggish thing here is that the window is larger than my monitor, but I cannot scale it down ?! (this is MATE - that is, Gnome2, desktop)

And here is the weird thing: I look up the symbol ElementImage, from an addon written in C++ - it finds a bunch of files, among others the .h file where it is defined; so far so good:

screenshot-codequery

Then I switch to "Class or Struct", and hit the "Search" button again - now there are no results whatsoever?!

screenshot-codequery-1

However, this does not happen always - if I look up TextureResource, everything is as expected - first as "Symbol":

screenshot-codequery-2

... and then as "Class or Struct" - there is even a small popup showing when I double-click select the class name in the code window:

screenshot-codequery-3

I understand much of the operation would depend on cscope and ctags - but why does this happen? One thing I could notice, is that in the headers, the non-problematic TextureResource class is declared as:

class TextureResource : public ReferenceCountable

... however, the ElementImage is declared as:

class ROCKETCORE_API ElementImage : public Element

... so maybe some of the underlying programs gave up on when it encountered the ROCKETCORE_API symbol?!

Well, this is probably a bug somewhere - but I'm not sure where; just thought it would be a good idea to report it. Would appreciate any guidance for solving this, if available.

commented

Hi @sdaau

cscope and ctags would do fuzzy parsing of the code, without full preprocessing.

So, it recognizes:

class <classname> :  public <classname>

But it does not recognize:

class <MACRONAME> <classname> : public <classname>

Because this fails the format expected by the fuzzy parser.

I have started another project to try to improve on this.