Re: make bootstrap-lean failure

[Toon Moene <toon at moene dot indiv dot nluug dot nl>]

Gerald Pfeifer wrote:

> On Mon, 26 Feb 2001, Erik Mouw wrote:

> > OK, found it. The file gcc/f/intdoc.texi wasn't touched for ages and
> > apparently has dependencies on gcc/f/intdoc.in. intdoc.in was newer
> > than intdoc.texi, 

Wow - that's pretty scary.  intdoc.in is from May, 3rd, 1999 in my
snapshot checkout tree ...

> > so the build process wanted to regenerate the texi
> > file and couldn't because it was read-only. The IRIX system doesn't
> > have makeinfo, so it didn't even try to build info files.
> >
> > So either intdoc.texi is out of date w.r.t. intdoc.in, or
> > contrib/gcc_update needs to touch it.

> Toon, how about this one? Do we need to update gcc_update? (Or has this
> been solved already, and I just missed that?)

I'm afraid I'm not particularly up to date with this stuff.  This is the
explanation from f/Make-lang.in:

# This dance is all about producing accurate documentation for g77's
# intrinsics with minimum fuss.  f/ansify appends "\n\" to C strings
# so ANSI C compilers can compile f/intdoc.h -- gcc can compile
f/intdoc.in
# directly, if f/intdoc.c #include'd that, but we don't want to force
# people to install gcc just to build the documentation.  We use the
# C format for f/intdoc.in in the first place to allow a fairly "free",
# but widely known format for documentation -- basically anyone who
knows
# how to write texinfo source and enclose it in C constants can handle
# it, and f/ansify allows them to not even end lines with "\n\".  So,
# essentially, the C preprocessor and compiler are used to enter the
# document snippets into a data base via name lookup, rather than
duplicating
# that kind of code here.  And we use f/intdoc.c instead of straight
# texinfo in the first place so that as much information as possible
# contained in f/intrin.def can be inserted directly and reliably into
# the documentation.  That's better than replicating it, because it
# reduces the likelihood of discrepancies between the docs and the
compiler
# itself, which uses f/intrin.def; in fact, many bugs in f/intrin.def
have
# been found only upon reading the documentation that was automatically
# produced from it.

# If the documentation files depended on executables in the build
# tree, there'd be no way to ship a source tree with the documentation
# already generated such that `make' wouldn't attempt to rebuilt it.
# So, we punt and arrange for the documentation files to depend on the
# dependencies of the executables, not on the executables themselves.
# But then, we have to build the executables explicitly in their build
# rules.

So - at least - f/intdoc.texi depends on f/intdoc.in *and* f/intdoc.c
*and* f/intrin.def (and f/intdoc.h which uses f/ansify).

Hope this helps,

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)