This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: Patch: `make tags' -vs- gdbtk, try 2
- To: tromey at redhat dot com
- Subject: Re: Patch: `make tags' -vs- gdbtk, try 2
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Thu, 28 Jun 2001 18:13:03 -0400
- Cc: gdb-patches at sources dot redhat dot com
- References: <87d7faiqpo.fsf@creche.redhat.com> <3A299DDA.5331A7EC@cygnus.com> <874s0mgrjp.fsf@creche.redhat.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)