| Greg's source code navigation tools: kscope |
|
||||||
|
|
|
|
|||||||||||
This page is part a log of an investigation I made of source code navigation and analysis packages starting in June 2005. I spent enough time on this particular product to find it more appropriate to dedicate its own page to it. I did an initial evaluation and decided I didn't like it. Then I got mail from the author making it clear to me (if not pointing out) that it would have been only polite to tell him what I thought rather than publishing it for him to find by chance. He's right. So I took a look at his message and tried again.
kscope is a KDE wrapper for cscope. KDE programs scare me, with reason: just installing it pulled in 86 (really!) other packages, including Samba and OpenLDAP.
Once I started it, it produced no useful output, and though I haven't given up, the interface turns me off: popups with windows too small to enter text in. It's reminiscent of k3b, with which I had so many problems in June 2005. After installing it, I couldn't get it to do anything useful, but the following day I managed to import some files (you have to specify the names as a subset wild card: * doesn't do anything). It can indeed display an upside-down calling function tree:
|
|
||||||||
Once again I have this terrible layout; the window is far too small, the text too big, the fields are truncated, I can't find a way to change the default size of the window, and there are not even normal resizing buttons. I've already told it to use smaller fonts, which it does in some places, but not here.
This is the window thrown up after you manually enter the name of the function (bp_wrap_file_write) and click on all the + boxes up to the top level call (in this case, process_connection). But I'm left wondering if it's worth the trouble:
In fact, the window contains (rather than displays) more information: it's hidden behind the scroll bars:
|
|
||||||||
You still can't do anything with it; the corresponding cscope output is more useful, since despite its unfriendly interface, it at least allows you at the sources.
I've never liked eye candy and GUIs for the sake of it, but in this case a GUI would be a good idea. It's sad that it has failed so badly.
As mentioned above, Elad Lahav, the author of kscope, sent me a message complaining that the criticism was unjust. He's right, and the very least I can do is address his issues.
He sent a number of suggestions, which I left until I had time to explore them completely. I finally started again on 18 August 2005. In case some of the problems might be related to FreeBSD, I tried it on SuSE Linux 9.3 this time.
After installation, which went without problems, I started the program, and it asked me for the locations of cscope and ctags:
|
|
||||||||
I don't know why: they were in the execution path. I selected Find and it started looking for them in the current directory.
|
|
||||||||
Then I discovered the Guess button, but by then it was too late. It wouldn't take a guess, and after restarting it didn't present the dialogue, though I had canceled any change. To actually find the programs, I had to use the which utility:
=== root@deeveear (/dev/pts/0) /src/BLFS/trunk.trunk/blockpool 48 -> which cscope ctags /usr/bin/cscope /usr/bin/ctags
The next step was to create a project. This was even more of a problem than last time. On the first attempt time it told me that the directory already existed, without specifying which directory. From the help file, it turns out that it tries to create a subdirectory with the name of the project, and this clashed with one of the existing subdirectories. I chose a different name and got:
Reading the help file shows that it wants a full path name; another example of the lack of UNIX-sensitivity. There's also no default for the path name, so when you start in the correct directory you still need to type in its (possibly long) directory name. When I did so, this message went away, so it seems that this error message is another way of saying “You didn't enter an absolute path name”.
After that, added the source files to the project and got a transient message saying that a process couldn't be started; but then it claimed:
|
||||||||||||||||||||||
It stayed like that for a long time, over 10 minutes, with no evidence of any progress. I killed the process and restarted. It didn't know the process. I had to manually search for it with the directory tree tool, after which I got the same messages as before.
I gave up with Linux and went back to FreeBSD, where things went beyond this stage; building the project file was practically instantaneous. I ended up with a large display of (unsorted!) file names with a couple of unidentified tabs at the top:
|
||||||||||||||||||||||
It turns out that you can sort the file names by clicking on the heading File. But what do the icons mean? They have no identifying text, even if you move the cursor over them. After searching the manual—which looks very nicely laid out—it appears that what I see should be the main window, but it's missing at least the source editor window in the middle. The window here is the file browser. The manual doesn't appear to document the meaning of the icons, but one seems to be a file view and the other a directory view. By default, the directory view starts at the root file system—yet another case where it ignores the current working directory—but it can be set there relatively easily.
One big problem is that the entire application opens only one window and panes it. The result is that even on a relatively high-resolution screen (1600x1200), everything doesn't quite fit:
|
|
||||||||
Click on the image several times to get the original size, which shows all windows except top left with something useful in them, but all of them are too narrow to display. It would have been so much simpler and more useful to make a separate window for each display.
| Greg's home page | Greg's diary | Greg's photos | Copyright |
