Re: [Cscope-devel] Vim issue and patch submission

[Ken S. <kg...@gm...>]

(resending because I didn't reply all)

2011/2/16 Hans-Bernhard Bröker <HBB...@t-...>:

> Actually, you would _always_ have to do cscope -R -b -q.  The ability to
> concatenate single-letter options that don't use arguments is a GNU feature
> offered by getopt_long().  No _GNU_SOURCE, no -Rbq.

Ok.  I'm compiling on Linux with the GNU compiler which doesn't define
it by default.  Is there a flag I should pass to configure to enable
_GNU_SOURCE or should I just edit the makefiles and add it to CFLAGS?

>> Also, when I try to use the cscope/vim integration, it fails on the
>> vim command, 'cs add cscope.out', with this message.
>
> VIM's cscope integration is handled by VIM, not by us.

It apparently relies on the single letter option concatentation.  When
I build cscope with _GNU_SOURCE vim integration works again.

>> relative path isn't valid.  This patch adds a flag (-a) to cause the
>> database to contain absolute paths which will allow remote cscope.out
>> files to be added and used easily.
>
> Maybe I'm overlooking something, but this sure looks like you've just
> re-invented the existing -Ppath option, but backward.

I tried getting -P to do what I want but I haven't gotten it to work.
When I do `cscope -Rbq && cscope -d -P$(pwd)', it launches me into the
ncurses interface.  When I do this, it still references the files
using relative paths.  The specific problem I'm trying to solve is
enabling loading multiple cscope.out databases that are not in $PWD.
The nonlocal cscope.out files contain relative paths.  Even if a
search finds nonlocal matches, the cscope instance can't find them.
I'm happy to learn that cscope already does what I want but so far, I
don't think -P does.  I'm happy to be proven wrong.

   ks