On 07.05.2014 20:17, Jemiah Aitch wrote: > I've been using cscope for years and there's one feature that I think would > be awesome. Specifically when using it with the Linux kernel many of the > search results aren't relevant to the build that's being worked on.
While that may be so, please keep in mind that cscope is a tool for inspecting the source. As in: all of it. It'll index code in non-taken #if/#else blocks, code in functions that aren't ever actually called, etc. And that's actually a good thing, because that way you won't miss stuff that's just disabled at the moment. Finding more than you were looking for may seem to hurt, but it's nowhere near as bad as _not_ finding stuff that you were, indeed, looking for, and never knowing about it. If you don't even see large parts of the source, any idea you form about the source by looking at that subset, and more so any change you make to it, is endangered by tunnel vision. You'll end up checking/changing "all" occurrences of a given name, but missing a good deal of them, because they weren't in your current filtered view. People will be _very_ cross with you if you submit a change that breaks virtually all builds of the kernel except the particular one you were looking at. > If there was a way to limit the search results to only contain hits > for source files that had actually been used for the last build it > would be awesome. So run cscope with a file list that holds only those files. Easy. Building that list is none of cscope's business, though. That would violate the "one tool <--> one task" principle of Unix. To make any sense, this file has to be built by make itself, using the actual Makefiles, and the same configuration options used to build the kernel + modules itself. The kernel Makefile already builds such a cscope.files, but it puts all available C sources in there, not just the active ones. IMHO, that's the correct way of doing it. ------------------------------------------------------------------------------ Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce _______________________________________________ Cscope-devel mailing list Cscope-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cscope-devel
