http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888
--- Comment #4 from Ralf Wildenhues <rwild at gcc dot gnu.org> 2010-10-07 04:57:28 UTC --- > --- Comment #2 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> > 2010-10-05 23:39:37 UTC --- > > The output produced by genhooks is not portable (newline encoding), so it > > should either produce binary output, or diff should be used to compare for > > changes. > > Sigh. What was supposed to give C programs more portability works against > us here. > > Using diff to ignore line-end space change would not really be satisfactory, > because then you'd get gratuitous changes in the checked in tm.texi whenever > there is a change in the newline encoding in effect when autogenerating a > changed tm.texi. Good point. Let's kill \r then. It should be possible to use tr -d '\015' on ASCII systems (\r is not portable to Solaris tr). So for portability you could pipe through this I guess: case `echo X|tr X '\101'` in A) # ASCII based system tr -d '\015' ;; *) # EBCDIC based system tr -d '\r' ;; esac > Unless we make the copy step do newline translation, that is. > So, what is the lesser evil in maintainability and portability? > Generating binary output with unix-style newlines (as we generally have > in our repository), or compare ignoring newline style and translating > while copying? > If we go for translating copying, do we make autoconf fail if no suitable > tool is found? There should always exist a suitable tool on systems where it is needed. FWIW, I would just use the above in the Makefile though (after removing the comments). > I've found a problem with a circular dependency, but the patch for > that didn't get reviewed: > http://gcc.gnu.org/ml/gcc-patches/2010-06/msg03046.html The hunk in that changing TEXI_GCCINT_FILES seems wrong, at least gcc/doc/gccint.texi still has '@include tm.texi' so that's what the dependency should be. > If references to source / build trees are 'messed up' in other ways too, > could you please be a bit more specific? I think that should be it. I was a bit confused when writing the message. Thanks.