This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 5/5] add libcc1
- From: Mike Stump <mikestump at comcast dot net>
- To: Jeff Law <law at redhat dot com>
- Cc: Tom Tromey <tromey at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Date: Thu, 31 Jul 2014 14:09:20 -0700
- Subject: Re: [PATCH 5/5] add libcc1
- Authentication-results: sourceware.org; auth=none
- References: <1400254001-12038-1-git-send-email-tromey at redhat dot com> <87oayx4l0x dot fsf at fleche dot redhat dot com> <87bntobp1f dot fsf at fleche dot redhat dot com> <53D9CA7B dot 3040709 at redhat dot com>
On Jul 30, 2014, at 9:47 PM, Jeff Law <law@redhat.com> wrote:
> So my biggest concern here is long term maintenance -- who's going to own care and feeding of these bits over time.
>
> My inclination is to go ahead and approve, but explicitly note that if the bits do start to rot that we'll be fairly aggressive at disabling/removing them.
So the normal way to do this would be to make the plugin front-end non-default and then never gate any release decisions upon the state of the that front-end. If it works, ship it, if it doesn’t ship it. If people want it to build, the contribute patches, if they don’t care, oh well…
That said, changes that ripple across front-ends generally need to be built with all (really all) built and are generally rejected if they break the build.
Given my experience with lessor front-ends (Objective-C and Objective-C++), I think we do a good job and the maintenance is fairly low. Others can disabuse me of this opinion if they want. My expectation is that this frontend will be easy to maintain and will be a non-issue. Everyone and then someone won’t test with it, they will break it, someone will notice, someone will contribute the 2 line patch that also makes it work, and life goes on. This is my experience with Objective-C++ (a non-default language).