bugmake - Bugs: bug #31326, Error message is way too terse

 
 

bug #31326: Error message is way too terse

Submitted by:  Bruce Korb <bkorb>
Submitted on:  Wed 13 Oct 2010 07:20:13 PM UTC  
 
Severity: 3 - NormalItem Group: Enhancement
Status: FixedPrivacy: Public
Assigned to: Paul D. Smith <psmith>Open/Closed: Closed
Component Version: 3.81Operating System: POSIX-Based
Fixed Release: 4.0Triage Status: None

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Sun 15 Sep 2013 09:54:57 PM UTC, comment #5:

For now I've enhanced the discussion of these error messages in the GNU make manual to suggest looking at variable values if you are not trying to create a static pattern rule. Some future enhancement that allows us to trace variable expansion in a useful way may make this even simpler to find.

Paul D. Smith <psmith>
Project AdministratorIn charge of this item.
Mon 19 Sep 2011 10:47:34 PM UTC, comment #4:

``or something like that''

Yeah, you wouldn't always do it and you'd have to decide on a
case-by-case basis when it might be appropriate.
So, several options for this:

  • wont-fix because the trouble/benefit ratio isn't good enough
  • consider an error-message-to-what-it-means doc, though

today's Googling gave a better answer than last fall.
But since Google results vary and can degrade and not everyone
can phrase queries in a way to get top results for best
answers, a "we may do that some day when we find spare time"
response sounds reasonable to me.....

  • identify messages that may need explanation and implement:

make --explain="multiple target patterns"
instead of a separate doc. That would be a Cool Thing.

  • a cheapie implementation:

errno=0;
if (fork() == 0)
system("$BROWSER http://lmgtfy.com/?q=gnu+make+%22multiple+target+patterns%22 ");
exit(errno);

Bruce Korb <bkorb>
Mon 19 Sep 2011 09:03:44 PM UTC, comment #3:

There's nothing make can do about this, that I can see. If your variable contains invalid syntax for a target then you won't see a problem until the variable is used in a target context, and that's where the error will happen.

I suppose make could print the contents of the line, as well as the line number, so you could see what the expanded line looked like to make when it failed. Or something like that.

Paul D. Smith <psmith>
Project AdministratorIn charge of this item.
Thu 14 Oct 2010 03:06:54 AM UTC, comment #2:

"Makefile:40" was the last line of the make file.
When I found the problem, it turned out that an
intervening script appended a path to a variable
and separated them with a colon. The dependency line
of the last rule had the two colons. Now that I
know the precise cause, I will try to reproduce it
with less than several thousand lines of make file
text. :( Thank you!

Bruce Korb <bkorb>
Wed 13 Oct 2010 07:30:45 PM UTC, comment #1:

Isn't "Makefile:40" the file/line information you're looking for?

Paul D. Smith <psmith>
Project AdministratorIn charge of this item.
Wed 13 Oct 2010 07:20:13 PM UTC, original submission:

Makefile:40: *** multiple target patterns. Stop.

In a huge project with a very twisty maze of includes,
it is crucial to be directed to the failing rule.
Without file/line information, or even the rule text,
there is just no way to chase back to the failure.

Bruce Korb <bkorb>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by psmith (Posted a comment)
  • -unavailable- added by bkorb (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 15 Sep 2013 09:54:57 PM UTCpsmithStatusNone=>Fixed
      Assigned toNone=>psmith
      Open/ClosedOpen=>Closed
      Fixed ReleaseNone=>4.0

    Back to the top


    Powered by Savane 3.1-cleanup