| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The option is called "depfile = gcc" and should support depfiles created
by GCC. GCC does not escape backslashes and GNU Make does not try to
unescape it, so neither should Ninja try to "unescape" it.
Only space (' ') and hash sign ('#') are specially treated by GCC/Clang.
Note that while tabs are also treated specially by GCC, Clang does not,
so do not special case it (why would someone use tabs in a filename?).
Support for 2N trailing backslashes in a filename is a bit questionable,
but is added to be as consistent as possible with GCC/Clang.
See also
https://github.com/llvm-mirror/clang/blob/44c160f916a1b080098b17b466b026aa07475ec2/lib/Frontend/DependencyFile.cpp#L316
https://github.com/gcc-mirror/gcc/blob/22a8377023d59cc01ab0a84a1df56d0e1336efa3/libcpp/mkdeps.c#L47
Fixes https://github.com/ninja-build/ninja/issues/1262
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prior to introduction of depfile parser handling of multiple rules,
ninja silently accepted a depfile of the form:
out: in1 in2 in3
other: otherIn1 otherIn2 otherIn3
and incorrectly treated `other` and `otherIn*` as additional inputs to
`out`. Now we prefer to reject this just as we already do for a depfile
specifying multiple outputs on one line. However, this can break
existing cases where such a depfile was silently tolerated.
Add a `-w depfilemulti={err,warn}` option to control this behavior,
and make it just a warning by default.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently we handle Makefile rules of the form:
out: in1 in2 in3
and the form:
out: in1 \
in2 \
in3
Teach the depfile parser to handle the additional form:
out: in1
out: in2
out: in3
This is also valid Makefile syntax and is the depfile format
generated by the Intel Compiler for Windows.
Note that the `gcc -MP` option adds empty phony rules to the generated
Makefile fragment:
out: in1 in2 in3
in1:
in2:
in3:
Previously we tolerated these because they were treated as inputs, which
was accidentally correct. Instead we must now tolerate these by
ignoring targets for which no dependencies are specified.
|
|
|
|
|
| |
Re-arrange the existing logic to support later addition of post-token
code even for empty tokens.
|
|
|
|
|
|
| |
This allows paths with "[", "]" and "%" to appear in depfiles.
Previously, only "[" would be handled properly.
Fixes #1227.
|
|\
| |
| | |
Allow paths with international characters in depfiles
|
| | |
|
|/
|
|
| |
This is a prerequisite for fixing #417.
|
| |
|
|
|
|
| |
Fixes #752.
|
|
|
|
|
|
|
|
| |
The range was added in 7ab6dcbdb6447861eefafc47fc3e10f3273cede2, but that
change only tried to add ! to the character class. Fix by moving '-' to the end
of the class.
Fixes #694.
|
|
|
|
|
|
|
| |
See http://llvm.org/PR15642. I checked that gcc does produce depfiles
containing "$$" for files with "$" signs in their name (and as of
r178540, so does clang). I also checked that .d files that escape dollar
signs with "\$" are not read correctly by make.
|
|
|
|
|
| |
See funny paths in
https://github.com/google/libcxx/tree/master/test/iterators/stream.iterators/istreambuf.iterator/
|
| |
|
| |
|
|
|
|
| |
Fixes issue #327.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Older versions of GCC would produce broken depfiles when -MT or -MQ is used
gcc43 -MT foo.o -MMD -MF foo.o.d -o foo.o -c foo.c
will result in the following depfile
foo.o foo.o: <dependencies>
Parse multiple outputs unifying duplicates and correctly report errors if
they are different.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
- '.' in re2c matches anything except \n, which means it matches \000.
Be more careful about which characters we match.
- The fallback rule [^] reads ahead another character, which means it
can read past the trailing \000. Add a separate rule to match it
specifically.
This was found by Valgrind.
|
| |
|
|
|
|
| |
Add some comments as well.
|
|
|
|
| |
From a patch from Allan Odgaard <github@simplit.com>.
|
|
|
|
| |
depfile_parser.cc file that's in version control.
|
|
|
|
|
|
|
|
| |
The logic was wrong if the input looked like
foo : bar baz
with a space before the colon.
Test from Frances <frances.buontempo@gmail.com>.
|
| |
|
|
|