This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]