bugmake - Bugs: bug #106, make reports misleading line...

 
 

bug #106: make reports misleading line number in error message

Submitter:  Paul D. Smith <psmith>
Submitted:  Sat 20 Apr 2002 08:44:50 PM UTC
   
 
Severity:  1 - Wish Item Group:  Enhancement
Status:  Fixed Privacy:  Public
Assigned to:  psmith Open/Closed:  Closed
Component Version:  3.79 Operating System:  Any
Fixed Release:  3.81 Triage Status:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 15 Feb 2006 11:57:16 PM UTC, comment #7: 

OK, fixed.  One thing I didn't change, because I didn't know which would be better, is the message generated by the --warn-undefined-variables flag.  It still shows the line number where the "top-level" variable is referenced, rather than where the undefined variable is actually referenced.  I can see both sides of this: you probably want to know where the variable was referenced, but you may also very much like to know where in the makefile the reference originated from.  Since I didn't know which was better I left it as-is.

Paul D. Smith <psmith>
Group administrator
Wed 15 Feb 2006 09:49:37 PM UTC, comment #6: 

Don't worry about it.  I think I have a handle on it.

Paul D. Smith <psmith>
Group administrator
Wed 15 Feb 2006 09:47:57 PM UTC, comment #5: 

Drat, you're right. Lemme have another look.

Jeff Evarts <jde>
Wed 15 Feb 2006 09:31:50 PM UTC, comment #4: 

You are correct, Jeff: make does actually have enough information to generate a more correct error message.  However, the patch you've applied is, I think, too generic.  There are some situations while expanding where you DO want the line number in the file and not the one associated with the variable.  For example, consider a variable that expands to a warning or error: with this patch the linenumber printed will be the one where the variable was defined, not where it was used, which seems less useful.

However, we can easily adapt the code into a better solution: the problem is we have only one variable, reading_file, when we need two: one that holds the current location in the file and the other that holds the current variable location.  Then, depending on the type of error that's being generated, we can pick the right one to use.  Errors related to expanding variables would use the variable context.  I can't implement this pretty quickly.

Paul D. Smith <psmith>
Group administrator
Fri 10 Feb 2006 02:35:03 AM UTC, comment #3: 

Closed bug #15340 as a duplicate of this bug.

Paul D. Smith <psmith>
Group administrator
Tue 07 Feb 2006 11:43:24 PM UTC, comment #2: 

Hrm, it appears that Make does know that factoid (struct variable containes a "fileinfo" element which seems to have The Right Thing in it) and there seems to be some relevant code in recursively_expand_for_file (expand.c) to handle the case where there is no context at all.

The attached diff does the right thing for the test case below, but may have side effects I don't understand. Or it might work.

Anonymous
Sat 20 Apr 2002 08:46:51 PM UTC, comment #1: 

Unfortunately right now when make is expanding text it has no idea what variable, if any, contained that text.  Also, the expansion could be many levels deep; it would be nice to show all the intermediate levels.  It's not clear how practical that is.

Paul D. Smith <psmith>
Group administrator
Sat 20 Apr 2002 08:44:50 PM UTC, original submission:  

When make finds a problem during expansion it lists the line number where the expansion occurred, even if the problem exists in a variable value which was actually assigned somewhere else.  It would be nice if make could report where the value was assigned as well.

Repeat:

$ cat Makefile
x = $(foreach )

all: ; @echo $(x)

$ make
Makefile:3: * Insufficient number of arguments (1) to function `foreach'.  Stop.

Reported via GNATS by -email is unavailable-

Paul D. Smith <psmith>
Group administrator

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #2050:  var-exp-diff.txt added by None (934B - text/plain)

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

Only logged-in users can vote.

 

Follow 8 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2006-04-01 psmith Fixed Release4.0 3.81
2006-02-15 psmith StatusNone Fixed
    Assigned toNone psmith
    Open/ClosedOpen Closed
    Fixed ReleaseNone 4.0
2006-02-15 psmith Carbon-Copy- Added -email is unavailable-
2006-02-07 None Attached File- Added var-exp-diff.txt, #3378
2002-04-20 psmith Severity3 - Normal None

Back to the top

Powered by Savane 3.13-758e.
Corresponding source code