I am trying to generate TAGS tables using etags for a large software project. The TAGS file ends up having entries to non-existent files at top level instead of the existent ones in a sub-directory due to #line directives in the lex/yacc generated .c files that refer to an unqualified file name instead of a #line that includes the sub-directory containing the file.
How can I get the TAGS tables to generate with these #line directives properly resolved to existing file in sub-directory instead of being interpreted as top-level files?
I run etags like this from top level directory:
rm -f TAGS; find . \( -not -regex '.*include/.*' \)
-a \( -name '*.h' -o -name '*.hh' -o -name '*.y' -o -name '*.l'
-o -name '*.cc' -o -name '*.cpp' -o -name '*.hpp' -o -name '*.c'
-o -name '*.inl' \)
| xargs etags -o TAGS --append
But I have a file, act/Par.c, that contains the following lines in the middle of the generated file:
#define T_NUM 274
#define T_STRING 275
#line 5 "Par.y"
#undef actCPMeshConfigIn_yywrap
#define actCPMeshConfigIn_YYMAXDEPTH 20000
Which results in TAGS table entries of the following:
act/Par.c,1160
[...]
#define T_NUM 92,2870
#define T_STRING 93,2888
Par.y,1320
#undef actCPMeshConfigIn_yywrap20,
#define actCPMeshConfigIn_YYMAXDEPTH 22,
But the file Par.y is actually located at act/Par.y, but the #line directive is relative to the current file, yet TAGS makes it relative to the generated TAGS file.
Without changing how I build the project, how can I generate the TAGS files so that these #line directives are properly interpreted as being relative to the file they occur within? Alternatively, how can I skip these troublesome files easily?
Solution is to instead run Exuberant Ctags in etgas mode and recursively. You cause exuberant ctags to run in etags mode by creating a link named etags to the exuberant ctags and it detects it was launched as etags and behaves appropriately:
Alternatively -e means etags mode: