Re: [tree-ssa] Integrating g95

[Steven Bosscher <s dot bosscher at student dot tudelft dot nl>]

OK, so here is a check list of what we need to do before we can pass 
that tarball to Diego (following the page Joseph pointed to):

   * A directory language under gcc containing source files for that 
front end. See The Front End language Directory, for details.

Check!!!

   * A mention of the language in the list of supported languages in 
gcc/doc/install.texi.

TODO

   * Details of contributors to that front end in gcc/doc/contrib.texi. 
If the details are in that front end's own manual then there should be a 
link to that manual's list in contrib.texi.

Just the link to our own docs will suffice?

   * Information about support for that language in gcc/doc/frontends.texi.

TODO -- probably with a hint that it is not complete yet.

   * Information about standards for that language, and the front end's 
support for them, in gcc/doc/standards.texi. This may be a link to such 
information in the front end's own manual.

TODO -- I think this again will just be a link to the g95 manual to-be.

   * Details of source file suffixes for that language and -x lang 
options supported, in gcc/doc/invoke.texi.

TODO

   * Entries in default_compilers in gcc.c for source file suffixes for 
that language.

TODO

   * Preferably test suites, which may be under gcc/testsuite or 
runtime library directories.

Check!!! We need to fix that broken forall test though ;-)

   * Probably a runtime library for the language, outside the gcc 
directory.

Check!

   * Details of the directories of any runtime libraries in 
gcc/doc/sourcebuild.texi.

TODO

   * At least one GNATS category for bugs in that front end and runtime 
libraries. This category needs to be mentioned in gcc/gccbug.in, and in 
gnats.html on the GCC web site, as well as being added to the GNATS 
database.

TODO -- what would be the appropriate name?  We should avoid confusion 
so that our bugs don't end up in the category for g77.

   * Normally, one or more maintainers of that front end listed in 
MAINTAINERS.

Paul, Toon and myself (when I finally contribute some patch again myself 
:))?

   * Mentions on the GCC web site in index.html and frontends.html, 
with any relevant links on readings.html. (Front ends that are not an 
official part of GCC may also be listed on frontends.html, with relevant 
links.)

TODO -- we could still mention Andy-g95, so this may be political...

   * A news item on index.html, and possibly an announcement on the 
gcc-announce@gcc.gnu.org mailing list.

TODO?  Just on index.html would be enough IMHO, or maybe not even that.  
Let's not blow horns and whistles over a half-finished front end.  
Suggestions?

   * The front end's manuals should be mentioned in 
maintainer-scripts/update_web_docs (see Texinfo Manuals) and the online 
manuals should be linked to from onlinedocs/index.html.

TODO -- but we do not have much of a manual yet.  I was actually kinda 
hoping Steven Kargl and maybe Katherine would like to help with that 
(hint :)), being native speakers with American spelling.  I plan to work 
on this as long as I'm unable to build gcc's on my "new" computer.

   * Any old releases or CVS repositories of the front end, before its 
inclusion in GCC, should be made available on the GCC FTP site 
ftp://gcc.gnu.org/pub/gcc/old-releases/.

This is something I suggest we do not.  We have our own CVS repository 
at SF, and we never had any official release, so no point IMHO.


   * The release and snapshot script maintainer-scripts/gcc_release 
should be updated to generate appropriate tarballs for this front end. 
The associated maintainer-scripts/snapshot-README and 
maintainer-scripts/snapshot-index.html files should be updated to list 
the tarballs and diffs for this front end.

Check!!! -- mostly.
The gcc_release part is done with the gcc_config patch.  The snapshot-* 
is TODO.  But do we really want to mention g95 in there?  tree-ssa is 
unreleased, so there will be no snapshots that contain g95 for many 
months to come.  I suggest we skip the snapshot part of this point and 
just keep the gcc_release like we have now.

   * If this front end includes its own version files that include the 
current date, maintainer-scripts/update_version should be updated 
accordingly.

I don't think we need our own version file.  Just the day-to-day version 
bumps that we have on the tree-ssa branch since a couple of weeks ago 
are good enough.

   * CVSROOT/modules in the GCC CVS repository should be updated.

Overseers issue???


The front end language directory and the the front end config-lang.in 
file are mostly OK.  Maybe a few details we overlooked, but these 
sections have to be satisfied to be able to build as part of GCC in the 
first place -- which we've been doing for some time now.

Does this commented list look OK?

I'll collect this TODO list and put it in our SourceForge CVS repo.


Gr.
Steven