This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [Forwarded] GPC 2.1 released
> > without good reason", but for the very concrete reason that some
> > things (like long URLs and too long lines in example code) sometimes
> > caused overfull boxes and didn't look good (to put it mildly) in the
> > manual. Since we offer DVI, PS and PDF files on our website and
> > might distribute printed copies in the future, I simply want to make
> > sure they look right (without looking through the files myself each
> > time).
>
> I don't see any real alternatives to making such checks carefully when the
> FSF want to print the manual (as well as generally e.g. keeping example
> lines short, putting long URLs on display rather than in running text).
Perhaps, but I guess this will happen rather seldom. In contrast, we
put a current copy on the manual on our website after each release
(and, of course, in A4 format becuase that's the standard and what
most of our users have), and we need to be able to do and check this
automatically.
> > As for not silencing TeX, what's become of the good old Un*x
> > principle that a command should be silent unless a problem occurs?
> > ISTM that this principle is not valued much in GCC (e.g., building
> > GCC produces some warnings that could probably be eliminated with
> > some effort, and `configure --silent' seems to be broken since 2.95
> > (*)), but I prefer it very much because this way I can do a complete
> > GPC build (including documentation and some cross builds) without
> > any output (except for the warnings in toplev.c), and when any new
> > problems (e.g., warnings) appear, I see them directly without
> > looking through a long output.
>
> Building produces a huge amount of make bootstrap output with the
> compilation commands anyway.
OK, though I don't need bootstrap since GCC is my native compiler,
anyway.
> TeX is (like Emacs) not a traditional Unix command; it's an application
> from some other operating system tradition that is now generally used on
> Unix.
Indeed.
> There's no clear definition of which output from it is useful to
> whom; sometimes underfull hbox warnings may be wanted, sometimes the list
> of files being read may cause one to notice the wrong file is being
> included or some file that should be included in the manual isn't.
Maybe, but I'm trying to catch as many bugs as possible (WRT to
actual occurrence in my experience) easily. There's always the log
file I can look at in case of doubt ...
> > If we can't agree in the other points, I think we could just just an
> > environment variable or two different build rules (or a configure
> > option, though I wouldn't know how to implement it) to support out
> > different needs.
>
> In general, try to make such features general - e.g., implement a
> configure option for all front ends. (And support for HTML and PDF
> manuals - probably using lang.html and lang.pdf Make-lang.in hooks -
> should similarly be done in some consistent way across front ends.
> There's no support for it in GCC at present, and it would be a good thing
> to add.)
Well, as I said, I'm not familiar with these issues, and since GPC
currently doesn't work with the current GCC frontend, it wouldn't be
of much use now. But I might try it after the integration ...
> > > put the contents
> > > list in the right place in the manual in the first place rather than
> > > reordering the .dvi file,
> >
> > Can I just move the `@summarycontents' and `@contents' after the
> > `@end titlepage', or is there anything to watch out for? (Since
> > gcc.texi until 2.95.x had them at the end, I wasn't sure if there
> > are any issues, so I rather wrote the dvi-reorder kludge to avoid
> > breaking anything else ...) Is a certain version of texinfo required
> > for it to work?
>
> Just put the contents commands in where you want them. texi2dvi will
> rerun TeX as many times as needed. The minimum makeinfo version for GCC
> is currently 4.1; certainly that version of texi2dvi, or indeed 4.0, will
> work. There were only problems with the old system of running tex;
> texindex; tex manually in the Makefile, rather than rerunning as much as
> needed for page references to stabilise.
OK, changed.
> (texi2html had
> problems with some of the macros used in GCC's manuals;
Same here. ;-)
Frank
--
Frank Heckenbach, frank@g-n-u.de
http://fjf.gnu.de/
GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)