Re: RFC: diagnose target clashes (for PR/344)

[Tom Tromey]

>>>>> "adl" == Alexandre Duret-Lutz <address@hidden> writes:

adl> I'd really appreciate comments on the following patch.
adl> The intent is to diagnose target clashes.  

adl> [...]/lib/am/program.am: ... `ctags' previously defined here.

adl> The locations could be improved but that's not the point here;
adl> for now I'm just using whatever location is available.  At least
adl> Automake doesn't produce a bogus Makefile silently.

adl>   1. update specflag7.test and specflag8.test to reflect they
adl>      now test for this feature
adl>   2. update ctags/etags example in the manual (probably change
adl>      it to egrep/fgrep...)
adl>   3. add tests cases for the new manual example (since 
adl>      specflag7.test and specflag8.test no longer test this)

I think improving the error location would also be good (especially in
light of Bruce's recent remarks on the main list).  If it is too hard
(perhaps it is) then we need a PR for it.

(BTW I've noticed you've been really good about submitting PRs and
stuff.  Cool.)

I think the idea is fine.  I'm a bit concerned by the FIXMEs about
redefining a target when there is a multi-target "foo bar baz:".

I didn't read the patch very closely.  At this point I'm sure your
judgement on implementation issues is more sound than mine.

What about setting things up now to reject targets that are in our
reserved namespace?  Do we want to actually reject them?  I suspect
so, though the counterargument is that overriding can still let the
user work around automake when necessary...

What about a section in the manual explaining how to build a program
whose name clashes with a standard target?

adl>  automake: `LDADD' is a target; expected a variable
adl> Now I'm wondering if this error still makes any sense today. I
adl> guess it was because targets and variables used to share the same
adl> namespace in older versions of Automake?

While what you say is definitely part of it, I think it might also
have been due to someone making a "spelling error" -- writing
"foo:..." instead of "foo = ...".  You'd have to dig in the logs to
find out for sure.  I'm not sure whether it is really worth diagnosing
this sort of problem.  In the old days I used to add warnings and
errors like this pretty randomly, based on bug reports I got.  But
there's a plausible argument that I was trying too hard to prevent
people from making mistakes.

Tom