What are the rules for etags, is it fair game to generate them for
variables defined in the build directory (as opposed to the source
directory)?
For instance, my editor can't find flag_generate_lto because the TAGS
rule in Makefile.in runs etags for source file *.h files (not those in
the build directory). Is it fair game to generate tags for "options.h"
in the build directory, as this patch does?
The attached patch would point flag_generate_lto to the extern
definition below. Not ideal, but close enough:
#ifdef GENERATOR_FILE
extern int flag_generate_lto;
#else
int x_flag_generate_lto;
#define flag_generate_lto global_options.x_flag_generate_lto
I suppose if we wanted to be pedantic, we should point it to the source
in common.opt, but that would require:
a) hacking etags to support our .opt language.
b) hack one of the opt*.awk files to generate ad-hoc TAG entries directly.
c) Or perhaps even, add semicolons to the end of variable entries in the
.opt files. That way, we could more or less trick etags into thinking
it's C. Though things like HOST_WIDE_INT variables would not work.
Yes, I'm that lazy. Why should I have to look around for something that
can clearly be automated?
Aldy
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 1b3820b..549e7a3 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -3792,6 +3792,7 @@ paranoia: paranoia.o real.o $(LIBIBERTY)
# Update the tags table.
TAGS: lang.tags
+ BUILD_DIR=`pwd`; \
(cd $(srcdir); \
incs= ; \
list='$(SUBDIRS)'; for dir in $$list; do \
@@ -3799,7 +3800,8 @@ TAGS: lang.tags
incs="$$incs --include $$dir/TAGS.sub"; \
fi; \
done; \
- etags -o TAGS.sub c-family/*.h c-family/*.c *.h *.c *.cc; \
+ etags -o TAGS.sub c-family/*.h c-family/*.c *.h *.c *.cc \
+ $$BUILD_DIR/options.h; \
etags --include TAGS.sub $$incs)
# -----------------------------------------------------
