7
To: Erik Carstensen
Cc: Duane Campbell; make-w32@gnu.org
Subject: Re: Any known problems with relative paths in VPATH on Windows?
> Date: Mon, 6 May 2013 21:55:11 +0200
> From: Erik Carstensen
> Cc: Duane Campbell , make-w32@gnu.org
>
> On Mon, May 6, 2013 at 9:48 PM, Eli Zaretskii
Windows has limits on path length, approximately (as I don't remember exactly
off-hand):
256 chars total in dir or file path
128 chars in each element in dir or file path
.duanec.
From: make-w32-bounces+dcampbell=nvidia@gnu.org
[mailto:make-w32-bounces+dcampbell=nvidia@gnu.org] On
> CreateProcess correctly on bat files, why don't you just give up the
> short-circuiting for all .bat files, and go through the cmd.exe invocation
> path (i.e., create a temporary bat file with the command invocation)
> whenever argv[0] ends with .bat?
I think gnu-make users need to be responsibl
I think the fundamental problem you are facing is:
- cmd.exe (and batch files) parse quoting one way.
- where-as programs parse the command line "any-way-they-please", usually (but
not always) using some compiler-language specific run-time-library (RTL).
(Unix shells are very different: the pars
This sounds very like a problem I had in 3.8.1.
This sound odd, but try adding one environment variable (to the caller's
environment).
If it's the bug I saw, it will likely hide the problem.
.duanec.
-Original Message-
From: make-w32-bounces+dcampbell=nvidia@gnu.org
[mailto:make-w
I see you single quoting - a ' is not a quoting character in Windows CMD shell.
In Windows CMD shell " is the (only) quoting character.
Note: There is no standard way to quote a " character in windows.
Windows opted to have applications parse the command line - hence no standard.
It is up to the p
If you want to make sure CMD's built-in "echo" is colled, not some "echo.exe",
then put a dot on the command.
echo foo
will find a .exe named echo if it can
echo. foo
will never find a .exe, so fallsback to the cmd.exe built-in
The same "append a dot" trick works for all CMD.EXE built-i
