Below is a description of a problem I ran into. Could you kindly check if you can reproduce this? If so, I've described my workaround at the end.
Set GTAGSLIBPATH to some project directory (I did not try with GTAGSLIBPATH set to multiple directories).
Open a program not contained in any project, and hit M-.
ggtags offers to create and then creates GTAGS, etc. in the directory pointed to by GTAGSLIBPATH.
Repeat M-.. Step 3 is repeated again! The GTAGS files that got created just a little while back are erased and created again.
From an email exchange on the global mailing list, it seems this happens because global needs to be always run from within a project. But then the behaviour of ggtags -- repeatedly creating the GTAGS files in GTAGSLIBPATH but never actually using them -- seems inconsistent to me.
In order to get around the restriction that global must always be run in a project, I'm using the following hack as a replacement for global now:
/usr/bin/global "$@" 2> /dev/null || (cd $global_home; /usr/bin/global -a "$@")
$global_home is a dummy project with one empty file called dummy.c.
I've suggested on the global mailing list that the behaviour + documentation of GTAGSLIBPATH be changed from
GTAGSLIBPATH
If this variable is set, it is used as the path to search for
library functions. If the given symbol is not found in the
project, global also searches in these paths. Since only
´GTAGS´ is targeted in the retrieval, this variable is ignored
when -r or -s is specified.
to
GTAGSLIBPATH
If this variable is set, it is used as the path to search for
library functions. If the given symbol is not found in the CURRENT
project, OR IF GLOBAL IS NOT BEING RUN FROM WITHIN
ANY PROJECT global also searches in these paths....
Not sure if global developers will pay any attention to the above. Pending upstream changes (if any), would it make sense to incorporate this behaviour within ggtags?
Below is a description of a problem I ran into. Could you kindly check if you can reproduce this? If so, I've described my workaround at the end.
From an email exchange on the global mailing list, it seems this happens because global needs to be always run from within a project. But then the behaviour of ggtags -- repeatedly creating the GTAGS files in GTAGSLIBPATH but never actually using them -- seems inconsistent to me.
In order to get around the restriction that global must always be run in a project, I'm using the following hack as a replacement for global now:
/usr/bin/global "$@" 2> /dev/null || (cd $global_home; /usr/bin/global -a "$@")
$global_home is a dummy project with one empty file called dummy.c.
I've suggested on the global mailing list that the behaviour + documentation of GTAGSLIBPATH be changed from
GTAGSLIBPATH If this variable is set, it is used as the path to search for library functions. If the given symbol is not found in the project, global also searches in these paths. Since only ´GTAGS´ is targeted in the retrieval, this variable is ignored when -r or -s is specified.
to
GTAGSLIBPATH If this variable is set, it is used as the path to search for library functions. If the given symbol is not found in the CURRENT project, OR IF GLOBAL IS NOT BEING RUN FROM WITHIN ANY PROJECT global also searches in these paths....
Not sure if global developers will pay any attention to the above. Pending upstream changes (if any), would it make sense to incorporate this behaviour within ggtags?