Re: [PATCH] etags support

[Tom Tromey]

>>>>> "Derek" == Derek R Price <address@hidden> writes:

Derek> I added rudimentary support for different implementations of
Derek> etags (read the one Automake expects and Exuberent etags) since
Derek> they take slightly different options.  Exuberent etags is the
Derek> version distributed with RedHat Linux 6.2 & I believe Debian
Derek> and a few others.

Hmm.  I'm running RH 6.2 and /usr/bin/etags is the GNU version:

    creche. etags --version
    etags (GNU Emacs 20.5)
    Copyright (C) 1996 Free Software Foundation, Inc. and Ken Arnold
    This program is distributed under the same terms as Emacs


It is pretty lame that the exuberant tags people chose to use the name
`etags' for their program.  The Emacs etags has been around since 1984
(though maybe it wasn't called "etags" until some time later; it
definitely was by 1990 though).  Surely they could have picked some
name that wasn't already in use.

I don't mind supporting some other version of tags, but I think it
would be easiest if we just introduced a new target.

Derek> This was enough to get the TAGS target working with CVS, but
Derek> what it probably still needs is a test for support for
Derek> "--lang=none" and a hook like @AMDEP@ to comment out the TAGS
Derek> target or support in missing for when the user doesn't have
Derek> etags installed or configure can't figure out how it works.

The `--lang=none' thing is definitely specific to the Emacs etags.
That must appear in your Makefile.am though -- meaning that your
Makefile.am was written to work with the Emacs etags.  This isn't an
uncommon practice, either.

I don't want to add missing support for etags.  tags is a developer's
target.  If a developer wants to use it, he should (1) know what etags
is, and (2) have it installed.

Adding configure machinery for this seems like overkill.

It's true that we do this for the C compiler, but the situations
aren't really analogous.

Tom