\r\n in dep files under windows + cygwin breaks ninja

[RedX2501]

When generated dependency files have \r\n in them ninja will not parse them properly. Instead it will output something like:

is dirtylain: \ is dirtylain: \ is dirtylain: \ is dirtylain: \ is dirtylain: \ is dirtylain: \ is dirtylain: \ is dirtylain: \ is dirtylain: \ is dirtylain: \ ninja explain: MCAL/bin/eTIMER_Gpt_LLD_IRQ.o is dirty

When piped to a file under vim i see:

1 ninja explain: ^M is dirty 2 ninja explain: ^M is dirty 3 ninja explain: ^M is dirty 4 ninja explain: ^M is dirty 5 ninja explain: ^M is dirty 6 ninja explain: ^M is dirty 7 ninja explain: ^M is dirty 8 ninja explain: ^M is dirty 9 ninja explain: ^M is dirty 10 ninja explain: ^M is dirty 11 ninja explain: ^M is dirty 12 ninja explain: ^M is dirty 13 ninja explain: ^M is dirty 14 ninja explain: ^M is dirty 15 ninja explain: CDD/bin/Cdd_Ssbm.o is dirty

Indicating that the \r in the file is culprit. Using the tool dos2unix on the generated depfiles let's ninja work properly confirming that the \r\n was at fault.

[nico]

Yes, depfiles don't support \r\n style newlines. (The error for this should be better.)

Where are you getting this depfile from? cygwin gcc's -MD -MD foo.d writes depfiles with just \n for me.

[RedX2501]

The compiler is called Windriver. Not very popular.

I think an option is to strip \r additionally then you get universal newline compatibility. I can't see any downside to that.

[nico]

Arguments for rejecting \r bytes in depfiles:

• gcc doesn't write \r\n newlines
• not reading \r bytes is marginally faster (less an issue now that we have deps mode)
• .ninja files don't support \r characters

Arguments for supporting \r in depfiles:

• depfiles are short makefiles, and make accepts \r\n line endings (on posix, too)
• some compilers apparently write depfiles with \r bytes
• it's slightly less code than printing an error message

I'm leaning towards accepting \r bytes in depfiles. If anyone has an opinion on this (e.g. if \r support in depfiles is useful for you, or if you can think of a critical flaw caused by supporting them), please let me know!

[nico]

I merged the patch to accept \r\n line endings. This should work better on trunk.