[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

["rwild at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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.