Hmmm. Well, it's natural to use find's -L option when making the
cscope.files, since compilers honor symlinks. Then again, maybe I use
cscope in strange ways; I want everything the compiler could possibly
get its dirty hands on, and I even throw in a libc tree, makefiles,
scripts, and the kitchen sink in there (yeah for the fuzzy parser).
So maybe all I needed was:
$ cscope -b
cscope: file foo.c is a symlink, ignoring it.
2010/8/12 Hans-Bernhard Bröker <HBBroeker@...>:
> On 12.08.2010 01:49, Stephane Belmon wrote:
>> Well, not like one would expect (maybe that's an understood behavior?)
> It's intentional behaviour. And it's been like that since 2001, i.e. for
> almost the entire history of the public version of cscope.
> There are two problem caused by allowing symbolic links to be counted as
> source files. The reason originally given when the change to lstat() was
> made back then was that symbolic links have a potential of causing problems
> by infinite recursion.
> The other is a slightly more practical one: there's arguably no point adding
> a symbolic link to the database anyway. You should add the actual source
> file instead. Among other things, that avoids duplicate entries in the
> database, which would make searches harder to work with.
> It's also somewhat unclear what's supposed to happen if, whether directly
> from cscope ('change this text string') or indirectly via the editor
> (Ctrl-E, edit all lines), a file is changed. Editing a symlink might edit
> the link target file, or it might be expected to copy the file and edit the
> copy instead.
> It's also unclear what to do about the timestamp of a symlink (important for
> the test whether to re-scan a file or just keep the scan results on database
Stephane Belmon <sbelmon@...>