[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: |
Eli Zaretskii |
Subject: |
[bug #29245] Bug with DOS Path in Secondary Expansion (with Fix) |
Date: |
Sun, 28 Mar 2010 08:49:29 +0000 |
User-agent: |
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; .NET CLR 1.1.4322) |
Follow-up Comment #1, bug #29245 (project make):
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.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?29245>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/