It's assumed that where we use DEPFILE in command or rspfile_content, it can be quoted by quoting the ninja variable (e.g. $DEPFILE -> '$DEPFILE') This is nearly always true, but not for gcc response files, where backslash is always an escape, even inside single quotes. So this fails if the value of DEPFILE contains backslashes (e.g. a Windows path) Do some special casing, adding DEPFILE_UNQUOTED, so that the value of depfile is not shell quoted (so ninja can use it to locate the depfile to read), but the value of DEPFILE used in command or rspfile_content is shell/response file quoted) (It would seem this also exists as a more general problem with built-in ninja variables: '$out' appearing in command is fine, unless one of the output filenames contains a single quote. Although forbidding shell metacharacters in filenames seems a reasonable way to solve that.) (How does this even work, currently? Backslashes in the value of all ninja variables, including DEPFILE were escaped, which protected them against being treated as escapes in the gcc response file. And fortunately, the empty path elements indicated by a double backslash in the value of depfile are ignored when ninja opens that file to read it.)pull/7245/head
parent
abf8bf488e
commit
5ca37e7961
1 changed files with 7 additions and 1 deletions
Loading…
Reference in new issue