From: Petr S. <pe...@sc...> - 2001-06-19 18:08:08
|
Hi, We also have to be careful of not being too language specific. Currently I use cscope for java/C/C++ programming with out too much trouble. As for using other progs like cxref and so on, is that cscope is under the BSD license which makes it more attractive to certain developers. Petr > > Hans-Bernhard Broeker <br...@ph...> wrote: > > > > > At the risk of being accused of heresy :-), I think that a tool like > > > GLOBAL would be better suited for this task than even a cscope -q mode > > > database. It already works by creating DB databases of function > > > definitions and calls and querying that, later. > > > > I've used GLOBAL. While it's very fast for lookups, indexing is so > > slow as to be unusable. If I recall correctly (it's been a few years), > > cscope runs 10-100X faster than GLOBAL at indexing. > > I just tried it a few days ago, and even though I didn't keep the times it > took, I seem to remember a difference more in the vicinity of a factor of > 3 to 10. And global seems to be relatively good at incremental updates of > its database, too (it doesn't have to bulk-copy the old one as part of the > process, for starters). > > > The GLOBAL databases are significantly larger than those of cscope, > > also. > > If you build all of them: yes. OTOH, I'm not quite sure this still holds > if you compare cscope -q with the equivalent call of gtags, which wouldn't > have to build all four of the GLOBAL table files, I think. > > > > Or apply existing tools for visualizing directed graphs (with a bit of > > > care, they'ld be acyclic) directly to the text output of cscope. > > > > That's nice, but my target is a tool that can be used with XEmacs. > > I'd like to make it a command-line tool, so that others could also use > > it. > > I'm not quite sure, but maybe borrowing some code from other call-tree > makers working with or without a cscope-style database (cxref, or > 'calltree' by J"org Schilling) could help. There's bound to be some > text-based graph analysis software out there, too. If nothing else, > the code that untangles the calltree inside (g)prof should help. > > [ambiguous function names occuring in several source files] > > > I guess I didn't make myself clear. Yes, it is possible to resolve > > these using human assistance, but I'm trying to make something that is > > simple to use (no human assistance, aside from possibly selecting a > > particular top-level function). Guesswork is a possibility, but I can't > > think of anything usable. Directory layout doesn't really work, as > > multiple definitions can occur within a directory (a situation that I > > have). > > Well, the only other choice would be to try and use the information > (hopefully) supplied by whoever was using those sources to group them into > sourcefiles --- i.e. parse Makefiles and look for targets that do links or > use 'ar' on groups of object files or C files. > > ... and cscope would have to learn to flag 'static' functions as separate > from truly global functions (and variables?). Currently, both are tagged > as '$', in the database. At least for the output meant to build calltrees > from, this would have to disambiguated (maybe by doing it like gdb, > accessing static functions via 'filename.c:function'. > > -- > Hans-Bernhard Broeker (br...@ph...) > Even if all the snow were burnt, ashes would remain. > > _______________________________________________ > Cscope-devel mailing list > Csc...@li... > http://lists.sourceforge.net/lists/listinfo/cscope-devel -- -------------------------------------------------------- Petr Sorfa Senior Software Engineer Caldera 430 Mountain Ave. http://www.caldera.com Murray Hill 07974 NJ, USA -------------------------------------------------------- Disclaimer: All my comments are my own and nobody else's ---------------------------------------------------------- |