make-w32
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: With SHELL=cmd, make fails to execute bat file paths starting with .


From: Eli Zaretskii
Subject: Re: With SHELL=cmd, make fails to execute bat file paths starting with ../
Date: Mon, 06 May 2013 19:14:30 +0300

> Date: Mon, 6 May 2013 09:08:04 +0200
> From: Erik Carstensen <address@hidden>
> Cc: address@hidden
> 
> I just thought it might be a more lightweight and robust solution for the
> other problem I reported earlier (spaces in .bat paths): You are detecting
> .bat files already, so instead of doing complicated special treatment  that
> relies on undocumented behaviour, it sounds easier to just fall back to
> non-short-circuiting path, so cmd.exe will handle that for you.

That's fine in principle, but not very easy in practice, given the
current design of the code structure.  The short-circuit path is done
much earlier, and once it is decided not to take the short-circuit,
the rules of quoting change radically, and the resulting command, and
accordingly its break down into argv[] array, are different.  OTOH,
the code which calls CreateProcess is way down the chain of command,
it is called when the entire command is already parsed into tokens.
It is only then that Make looks for argv[0] in the standard places,
and constructs its full absolute file name.  Only then we know whether
it's a batch file and whether it has blanks anywhere in its name.

To implement your suggestion, we need to restructure the code in a
significant manner.

(Btw, calling CreateProcess with first argument NULL is an officially
documented method, it's described on MSDN.)

> For some reason I was trying to avoid backslashes in makefiles, because I
> thought make doesn't like those in dependency lists etc. Apparently that's
> just a prejudice; \ seems to work nicely everywhere.

The only place where it might not work is in arguments to the wildcard
function.  If you see backslashes failing to work anywhere else,
please report that as a bug.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]