A long time ago in a galaxy far, far away, I ran into a small program named cscope. It didn't do much. It just databased every symbol in a C source tree (including #include files) and let me search them powerfully.
A long time ago in a galaxy far, far away, I ran into a small program named cscope. It didn't do much. It just databased every symbol in a C source tree (including #include files) and let me search them powerfully.
I immediately put it to use, and it made navigating large projects a breeze. Sure, grep + vi does some nice things when hunting symbols, but not like this. Even better, cscope allowed tracking of symbols and files. This meant that I didn't have to hunt which file called foo_func(). Cscope would tell me.
Alas, cscope was written by AT&T in the good old days of AT&T Unix. The license? Pay for everything AT&T provides in Unix development tools. The copy I had discovered was on an AIX machine, shown to me by an AIX kernel developer. I could use it, but I had no source.
Most of my hacking is on Linux. I had no cscope for Linux. It did not become an everyday tool of mine. Rather, I pulled it out of its box when I desperately needed it. I would upload sources to an AIX machine just to examine them when they confused the bejezus out of me.
What of free alternatives? There is cs, a free clone. I tried it. It was not really usable, both from an UI standpoint and what it tracked. uzi put together nice shell wrappers for the old grep/vi tricks in his package cgvg, but they didn't do what I needed, and like most folks, I am already used to the hand-tracking of grep/vi searching. He has since started a cscope clone, but that is for future release.
Imagine my surprise when I discovered today that SCO has posted the cscope sources on SourceForge. Sure enough, it is an "i386" build tree. What happened to the support for most SysV/BSD/etc unices, I dunno. It is probably a couple tweaks away. They claim the soonest TODO is auto* support.
Needless to say, I am a happy camper. I've been waiting for this. Of course, who knows what license issues will come down (SourceForge says BSD License). Other issues may crop up. In the meantime, a powerful tool that I find extremely useful is finally available on the Linux platform.
I was surprised and pleased to see cscope released... I was working on making an open sourced clone (not too far along yet) of it with added features. I've grabbed the offering from SCO, and it's mostly the version I knew and loved while I was working at Sun, with some bugs. The initial complaint I've heard is that it doesn't work with Debian or OpenBSD, but it works mostly fine on my Redhat machines. The code looks like it was meant for i386, but using that Makefile worked on my Sparc Redhat machines. I've also noticed that the compressed database when not using the '-c' option is a bit messed up in some instances.
Moving forward, though, I'm interested to see how SCO will treat things. I've already noticed a few things I want to add/fix/change, and depending on the response I get, I'll either work on this version, make a new fork, or go back to rolling my own.
It's definitely great that we have this great tool at our disposal now... kudos to SCO for doing this... so I'm curious as to why they released version 13.0 rather than the most recent (which is some 13.x.y, x ~= 7)...
The initial complaint I've heard is that it doesn't work with Debian...
It works fine with Debian after changing /usr/tmp into /var/tmp in the definition of TMPDIR in main.c. I also noted it builds and runs fine without any further modifications on Debian/Alpha. Haven't tried any other architectures yet.
Now if we could just get a lint clone that builds on Linux... NetBSD's lint is pretty good but it's inextricably tied to the BSD file tree.
ruud: good call, dude... I've been too busy looking at some of the other bugs I've encountered... and on Redhat machines I have here (Sparc and x86). Odd using /usr/tmp instead of /var/tmp ... must be a SCO-ism...
Back in the old days there *wasn't* a /var... you had /usr/spool, /usr/tmp/, and so on. Looks like SCO is still remaining compatible with Xenix-86. That was their first product, after all.
The BSD nvi has hooks to talk to cscope, as I recall. At least, the author mentioned that to me in email a long time ago;; I wasn't able to try it at the time, since cscope wasn't free.
You might also want to look at mkid, a set of tools for indexing source code. They are GNUware these days I think, and are pretty useful. Of course, ctags goes a long way too. None of these is especially good with C++ or Java.
Oh, and /usr/tmp was on a slower disk on the early research Unix system, and was intended for larger files than /tmp, which was small. It was moved to /var/tmp so you could mount /usr/read-only; some systems have a symlink from /usr/tmp to /var/tmp.
The program nvi which comes with FreeBSD (and possibly other *BSD's) has a little document cscope.NOTES on how it was extended to support cscope.
Another useful utility for search large source trees is glimpse. It will create a database which can be quickly search. You can use eregex with it, and it can search 30+megs of data in a fraction of a second.
I haven't tried running cscope on something like FreeBSD's kernel, but I will in the near future. Getting cscope to compile under FreeBSD was easy, changed some curses.h to ncurses.h, change wait.h to sys/wait.h, and remove some duplicate declarations.
2. Works derived from this code are not distributed for commercial gain without explicit permission from MIT (for permission contact lclint-request@sds.lcs.mit.edu).
Linux binaries are available.
Eivind.
lclint has been GPLed since at least the current version (2.4b). There's a web site.
Could you please substantiate your claim that lclint is under the GPL? I looked for licensing references on the web site before posting my article, and did not find any. The license quote comes from the "LICENSE" file in the lclint-2.4b distribution. The distribution contains references to the GPL in the cpp part (which is derived from the GCC preprocessor) and the configure script, but not in the main program.
Eivind.
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!