[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #29245] Bug with DOS Path in Secondary Expansion (with Fix)
From: |
Paul D. Smith |
Subject: |
[bug #29245] Bug with DOS Path in Secondary Expansion (with Fix) |
Date: |
Thu, 01 Jul 2010 06:44:51 +0000 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.6) Gecko/20100628 Ubuntu/10.04 (lucid) Firefox/3.6.6 |
Update of bug #29245 (project make):
Status: None => Not A Bug
Open/Closed: Open => Closed
_______________________________________________________
Follow-up 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:
D := C:
foobar.o: $$(call func,$$D/foobar.c)
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.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?29245>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [bug #29245] Bug with DOS Path in Secondary Expansion (with Fix),
Paul D. Smith <=