Georg-Johann Lay wrote:
The avr backend auto-generates parts of GCC's texi documentation, namely the supported -mmcu= options, which are about 200.To generate the texi a small C program is used to print the texi to stdout, and that output is then compared against the already existing doc/avr-mmci.texi If the output is the same like in that file, nothing happens. If the output differs from that file, the user (someone building the avr compiler) is nagged to update the existing documentation so that the documentation says in sync with the compiler. The part of t-avr reads: s-avr-mmcu-texi: gen-avr-mmcu-texi$(build_exeext) $(RUN_GEN) $< | sed -e 's:\r::g' > avr-mmcu.texi @if cmp -s $(srcdir)/doc/avr-mmcu.texi avr-mmcu.texi; then \ $(STAMP) $@; \ else \ echo >&2 ; \ echo "***" >&2 ; \ echo "*** Verify that you have permission to grant a" >&2 ; \ echo "*** GFDL license for all new text in" >&2 ; \echo "*** avr-mmcu.texi,then copy it to $(srcdir)/doc/avr-mmcu.texi" >&2 ; \echo "***" >&2 ; \ false; \ fi The problem is comparing the new texi file avr-mmcu.texi against the already existing $(srcdir)/doc/avr-mmcu.texi and factor out different line endings that depend on the build system like LF vs. CRLF. What is the best way to do such a comparison on text level without getting a complaint if the original texi was built on linux and the user builds the compiler under, say, windows? How to cope with different line endings in that case?
Instead of trying to cope with different line endings on the generated files, wouldn't it be better to modify the C program to output the desired line ending format in the first place? Instead of just writing a \n in text mode, output \n\r in binary mode (if you want DOS format), or just \n (for unix format). I'd think changing the line ending format on a file should be considered a problem, as the distributed files could end up in numerous formats, making nobody really happy.
