This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
handling changes to the front-end interface
- To: Nicola Pero <n dot pero at mi dot flashnet dot it>
- Subject: handling changes to the front-end interface
- From: Fergus Henderson <fjh at cs dot mu dot oz dot au>
- Date: Tue, 6 Mar 2001 16:04:48 +1100
- Cc: gcc at gcc dot gnu dot org
- References: <20010305154219.O21391@wolery.stanford.edu> <Pine.LNX.3.96.1010306041246.9990A-100000@leonardo>
In gcc-patches and gcc-bugs, on 06-Mar-2001,
Nicola Pero <n.pero@mi.flashnet.it> wrote:
>
> [someone wrote:]
> > It looks like no one updated the ObjC front end for this change:
>
> I wonder if it was not the responsibility of the person who made the
> change to update it.
When making changes like that, I think the best that you can reasonably
hope for is that the person making the change will try reasonably hard
to avoid introducing such problems, and will run the test suite to see
if their change nevertheless does introduce any regressions. It is the
responsibility of the person making such a change to test it, but it is
also the responsibility of language front-end developers/maintainers
to ensure that the test suite contains a reasonable test suite for
their language. If the test suite for a particular language doesn't
cover enough of the language, then yes, the front-end for that language
will break.
(If I understand correctly, the changes in question which broke the
Objective C front-end were not detected by any of the existing test cases?)
> Or - at least - he should have warned people working
> on other front ends (other than C/C++) that they needed to update their
> front ends, and how.
This change was documented in the LANGUAGES file, which exists for precisely
that purpose.
I've been monitoring the gcc lists recently to look for changes that might
affect the Mercury front-end. But I probably won't have enough time and/or
patience to do that indefinitely. If/when I stop, I sure hope the gcc
developers continue to maintain the LANGUAGES file (or some equivalent).
> Wouldn't it be simpler if the person who makes a change in the core of gcc
> - which could break frontends - updates the frontends kept in the gcc
> repository and informs external developers that they need to update
> theirs, and how ? I know this adds quite a overhead for the core gcc
> hackers - all quality procedures adds a certain overhead - but what relief
> for front ends.
Language front-end maintainers do need to monitor the LANGUAGES file.
Would it be worthwhile setting up a new mailing list `gcc-frontends',
and modifying the CVS loginfo file to send diffs for changes to the
LANGUAGES file to that list? (Perhaps also for changes to tree.h and
tree.def? Maybe even toplev.h too?)
If people think it is worthwhile, I'd be happy to fix the loginfo file
to do that, and to patch the web pages to mention the new mailing list.
But someone with appropriate access would need to actually create the list.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.