This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

TAGs for variables created through common.opt

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 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:

extern int flag_generate_lto;
  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?


Attachment: curr
Description: Text document

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]