Re: 76-tags-in-tags-am.patch

[Akim Demaille]

>>>>> "Tom" == Tom Tromey <address@hidden> writes:
>>>>> "Akim" == Akim Demaille <address@hidden> writes:

Akim> This patch introduces one semantical difference: tags-recursive
Akim> is bound to tags, not TAGS as was before.  I think (i) it is
Akim> cleaner, and (ii) anyway it seems to me that TAGS itself
Akim> performs its own recursion:

Tom> The "recursion" in TAGS is different.  tags-recursive should be
Tom> running `make tags' in each subdir.  In TAGS we look for a TAGS
Tom> file in each subdir and if it exists we include it in the TAGS
Tom> file we are creating.

Ah!  That's the thing.  Thanks!

Tom> The thing is that `tags' is really a convenience for people who
Tom> don't like upper case.  It is a historical thing and not
Tom> mandated.  TAGS is the name of the mandated target.

Hm, it's seems a bit contradictory: tags is a convenience for TAGS,
but it's different?


Tom> So I think `make TAGS' has to do all the recursion.  Maybe we
Tom> currently get this wrong, since the recursive invocation invokes
Tom> `make tags' and not `make TAGS'.

I'm tempted to understand you say the same thing (tags: TAGS period),
but I'm not sure.


Akim> Another question is why don't we use the regular -am, -recursive
Akim> mechanism?  Given that we always output a `tags' and `TAGS'
Akim> target, it should be equivalent and much simpler: just
Akim> RECURSIVE_TARGATS += tags-recursive.

Tom> Because the recursive tags invocation should never fail.  Maybe
Tom> it is ok if a tags failure in a subdir propagates upwards, since
Tom> it means there's a bug somewhere.  I'm ok with that change if you
Tom> want to make it.

Given that local TAGS targets cannot fail, I'd say we should hook
ourselves on the regular mechanism.


Then, I'd say we should have TAGS work all by itself, calling
TAGS-recursive.  And tags is nothing but `tags: TAGS'.  How does it
sound?