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

[amylaar at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888

--- Comment #2 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> 2010-10-05 23:39:37 UTC ---
(In reply to comment #0)
> The thread starting at:
> <http://gcc.gnu.org/ml/gcc/2010-10/msg00020.html>
> lists a number of issues around tm.texi:
> 
> 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.
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?  Would that be specific to --enable-maintainer-mode?  Or do
we postpone the failure till the tool is actually needed?

> The tm.texi rule is broken because it references non-existing
> $(srcdir)/doc/target.def.

Mea culpa.  That should be just a plain $(srcdir)/taget.def .

>  Also, it seems references to source and build tree
> are a bit messed up.  The logic to trigger a warning for updating the wrong
> file could need a look-over, too.

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

If references to source / build trees are 'messed up' in other ways too,
could you please be a bit more specific?