bugmake - Bugs: bug #29245, Bug with DOS Path in Secondary...

 
 

bug #29245: Bug with DOS Path in Secondary Expansion (with Fix)

Submitted by:  None
Submitted on:  Wed 17 Mar 2010 12:07:43 PM UTC  
 
Severity: 3 - NormalItem Group: Bug
Status: Not A BugPrivacy: Public
Assigned to: NoneOpen/Closed: Closed
Component Version: 4.0Operating System: MS Windows
Fixed Release: NoneTriage Status: None

Add a New Comment(Rich Markup)
   

You are not logged in

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

 

Thu 01 Jul 2010 06:44:51 AM UTC, comment #2:

I agree with Eli: this is not a good change.

The problem is not at all related to the comma, not really: the problem is with make's use of ":" as a special separator character, and with Window's use of ":" as a drive specifier character. They have an uneasy coexistence at the best of times, and this situation is simply one special case too far I believe.

Make isn't tracking a function call here because this is NOT a function call: the double-$ escapes the function call-ed-ness and so make is simply treating this as a string... and looking for a second ":" to see if it's a static pattern rule. It finds one, and hence the error.

One straightforward way to work around this is to hide the colon in a variable; IMO it's better to use a variable to hold the drive anyway; hardcoding the drive name is not very nice:

I recognize that this is not nice, but make syntax is simply not up to the job of allowing any filename to be considered a target or prerequisite.

Paul D. Smith <psmith>
Project Administrator
Sun 28 Mar 2010 08:49:29 AM UTC, comment #1:

Sorry, but I don't like this solution. A comma is a legitimate file-name character on Windows, used, e.g., in RCS files. Using it as a delimiter here will cause Make to misdiagnose other syntax errors. For example, just remove the $(call) from the attached example, to produce this line instead of the last one:

foobar.o: func,C:/foobar.c

The comma is only a delimiter when it's inside a function call. The problem is that `eval', the function where the change is proposed, does not track function calls (AFAICS), and does not know that it is inside such a call. I would agree to treating the comma specially inside function calls, but that would require much more extensive changes.

A workaround for the original poroblem is to have a single blank after the comma. Then Make behaves as expected with the provided sample Makefile.

Eventually, it's up to Paul: if he doesn't mind to have Make on Windows display incorrect diagnostics when commas are used in file names, then maybe we should accept this change.

Eli Zaretskii <eliz>
Project Member
Wed 17 Mar 2010 12:07:43 PM UTC, original submission:

There's an issue regarding the use of a DOS paths in a secondary expansion. Here's a minimal Makefile to demonstrate it:

-----------------------------------
.SECONDEXPANSION: foobar.o
.PHONY: C:/foobar.c

func = $1

foobar.o: $$(call func,C:/foobar.c)
-----------------------------------

The code above triggers the unsubstantial error message:

makefile:6: *** multiple target patterns. Stop.

The fix is to change line 1148 in read.c from:

(p == p2 + 1 || strchr (" \t:(", p[-2]) != 0)) {

to:

(p == p2 + 1 || strchr (" \t:(,", p[-2]) != 0)) {

Oliver Schmidt - oschmidt(at)sap.com

Anonymous

 

(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 eliz (Posted a comment)
  •  

    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 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 01 Jul 2010 06:44:51 AM UTCpsmithStatusNone=>Not A Bug
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup1