This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [Forwarded] GPC 2.1 released
- From: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- To: Andreas Jaeger <aj at suse dot de>
- Cc: Matthias Klose <doko at cs dot tu-berlin dot de>, <gcc at gcc dot gnu dot org>, <frank at g-n-u dot de>
- Date: Sun, 12 May 2002 15:25:11 +0100 (BST)
- Subject: Re: [Forwarded] GPC 2.1 released
On Sun, 12 May 2002, Andreas Jaeger wrote:
> GPC is still using GCC 2.95. Are there plans to support GCC 3.1 - and
> to integrate GPC into the GCC repository?
Integration means - ought to mean - more than just supporting GCC 3.1, in
that to be integrated it ought to follow established good practices for
front ends. For example:
* Runtime library in a separate toplevel directory (needed for multilibs
to work properly). (This one, especially, is desirable to do before
adding it to the GCC CVS, rather than moving files once in CVS. Ones
that don't involve mass moving of files are more reasonable to do after
it's in GCC CVS for more people to work on them, provided there's a
commitment from the people integrating it to do everything necessary to
make it a smoothly integrated front end following good practice and not
doing things arbitrarily differently without good reason.)
* Testsuite using dejagnu (needed to integrate properly into existing
regression testers).
* Obviously, all the conditionals and diffs relating to support for
different versions of GCC gone (since once it's integrated it need only
support the CVS version of GCC it's included in).
* Obsolete things such as diff_excludes in config-lang.in gone.
* Using only Make-lang.in, no separate Makefile.in for the front end
directory.
* Integration of build/install instructions into main GCC installation
docs.
* Building docs in a way more similar to those for the other front ends.
(E.g., don't silence TeX, don't fail for overfull hboxes (since people can
configure Texinfo for their own paper size and you can't reasonably ensure
that the manual is perfect for every paper size - actually setting the
paper size in the manual, except for FSFPRINT, is wrong), put the contents
list in the right place in the manual in the first place rather than
reordering the .dvi file, use makeinfo --html for HTML manuals [there
isn't any standard for building them from Makefiles, but it's what
onlinedocs do].)
(If it actually gets close to integration in general, I can go over what
should be done with the docs for consistency and integration with the rest
of GCC in more detail. But you should at least first make a pass over
them with reference to the "Spelling, terminology and markup" section of
codingconventions.html, so there aren't problems of that level to point
out.)
* Using the GNU Free Documentation License for manuals.
* See also the list in "Anatomy of a Language Front End" in
sourcebuild.texi, to ensure that when adding it you do add a complete
front end, with all the associated documentation etc. bits needed.
--
Joseph S. Myers
jsm28@cam.ac.uk