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

[Alexandre Duret-Lutz]

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

[...]

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

PR/360 & PR/353.  I wholeheartedly agree fixing these would be
good, but I think this shouldn't hold the realease.  Producing
an error message, however vague, is an improvement over
producing a bogus Makefile.

(Fixing PR/353 to produce error messages similar to those of
this patch should be relatively easy, though.)

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

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

To clarify, I'm just documenting an existing issue, not
something I've added.  I'm concerned by the numerous FIXMEs
that pile up in this area too.

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

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

Maybe we can let people who have to play this kind of trick tell
Automake so with -Wno-reserved?

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

Sure!  Short of _NAME, what do we recommend?

Jim's

  bin_PROGRAMS = ginstall
  transform = s/ginstall/install/; @program_transform_name@

?

 adl> automake: `LDADD' is a target; expected a variable

By the way, the missing location here is probably a bug in my
msg_target change in this patch -- I'll look at this.

 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?

 Tom> While what you say is definitely part of it, I think it might also
 Tom> have been due to someone making a "spelling error" -- writing
 Tom> "foo:..." instead of "foo = ...".  You'd have to dig in the logs to
 Tom> find out for sure. 

Didn't find anything explicit.

Tue Apr  9 22:53:16 1996  Tom Tromey  <address@hidden>

        * automake.in (variable_defined): New function.
        [...]
        Many changes to use variable_defined.

+# See if a variable exists.
+sub variable_defined
+{
+    local ($var) = @_;
+    if (defined $targets{$var})
+    {
+       &am_line_error ($var, "\`$var' is target; expected variable");
+    }
+    return (defined $contents{$var} && ! defined $targets{$var});
+}

 Tom> I'm not sure whether it is really worth diagnosing this
 Tom> sort of problem.  In the old days I used to add warnings
 Tom> and errors like this pretty randomly, based on bug reports
 Tom> I got.  But there's a plausible argument that I was trying
 Tom> too hard to prevent people from making mistakes.

We can restrict this check to user-defined targets.  
This way `bin_PROGRAMS = LDADD' won't fail.

Would it makes sense to rename -Wunused (warnings about unused
variables) into -Wtypo (potential typos) and turn this error
into a 'typo' warning?
-- 
Alexandre Duret-Lutz