Re: wwwdocs/htdocs/egcs-1.1/fortran.html

[Jeffrey A Law <law at hurl dot cygnus dot com>]

  In message <19990228203445.31046.qmail@deer>you write:
  > >http://egcs.cygnus.com/cgi-bin/fortrannews
  > 
  > Cool!  Would you be willing to engineer a similar feat for the bugs.texi
  > info?
Done.  Yup, 15 seconds ;-)  

http://egcs.cygnus.com/cgi-bin/fortranbugs

Same script, different texi file input file :-)

What might make sense is to have a fortran page linked into the main site
which would contain links to the cgi scripts.  We could do the same for the
other front-ends.  The page would have, well, anything the maintainers thought
needed to be on the web.

  > For the short term, this specific info would be nice to have
  > made available automatically via the web page.
Can't argue with that.  Even if we completely change directions with this
stuff later, having the info easily available on the web in the short term is
a good thing.


  > (I'm not sure what to suggest about those unresolved "@xref"'s, though.)
Me neither.  I think this argues that the entire manual should be online
instead of just sections we convert on the fly.

In that kind of setup the "bugs" link would point to the label in the html-ized
version of the complete manual.  Let me play with that a little and see if
it actually works :-)

  > Actually, more generally, I'm interested in seeing a high-level web
  > page that gives people access to the lists of:
  > 
  >   A.  New (user-visible) changes
  > 
  >   B.  All visible changes
  > 
  >   C.  Known bugs
  > 
  >   D.  "To-do", or "projects", items
Yup.  I think this is a good example of what belongs on a generic fortran
(or C++, C, Chill, target, or optimizer) page.


  > Then, for each of these lists, it'd be nice to offer this kind of
  > breakdown:
  > 
  >   a.  Infrastructure.
  > 
  >   b.  Compiler back-end (code generation plus ports).
  > 
  >   c.  Front ends (per-language).
  > 
  >   d.  Libraries.
  > 
  >   e.  Tests.
Either way should be fine.  I'm not sure if the toplevel would be specific
to a part of the compiler (C, C++, Fortran, etc), then the specifics
(bugs, user visible changes, todos, etc) or vice-versa.

The structure of the existing texi documentation may push us in one direction
or the other initially.


jeff