Re: Patch: `make tags' -vs- gdbtk, try 2

[Andrew Cagney <ac131313 at cygnus dot com>]

> Andrew> Should the logic be reversed - don't do anything special for
> Andrew> gdbtk?
> 
> We could do that for the .c and .h files.  I didn't look deeply into
> the non-gdbtk cases.  Interestingly I just found that mi/*.c do not
> appear in TAGS.


Yes, there will be other directories also.  Apparently H.P. have a 
python directory.

 
> One problem with doing a blanket "find $(srcdir) -name '*.[ch]'" is
> that this can pick up files and directories that aren't in CVS.  I
> sometimes rename some files (eg, by putting them in a subdir) in order
> to temporarily back out a patch.  In this scenario the tags file would
> end up with two entries for some symbols.  This can be confusing.


I think we can live with this :-)


> I don't want to spend the time to make the gdb TAGS creation process
> completely bulletproof.  (If you really wanted that you'd be using
> automake anyway :-)
> 
> However, I am willing to implement the quick and dirty `find' solution
> (with exclusions) if that is what you want.


Yes, the main thing is to avoid explicitly refering to the directory 
gdb/gdbtk.


> BTW gdbtk will always need at least one special case because
> generating tags for Tcl code requires the use of the magic `--regex'
> option to etags.


That I think is ok.  Other people will add similar rules for their local 
scripting language.

	Andrew

(Sorry to leave this dangling)