This is the mail archive of the
mailing list for the GCC project.
Re: is it time to mass change from .c to .cc in gcc/ ?
- From: Trevor Saunders <tbsaunde at tbsaunde dot org>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: GCC Development <gcc at gcc dot gnu dot org>
- Date: Tue, 14 Apr 2015 20:09:11 -0400
- Subject: Re: is it time to mass change from .c to .cc in gcc/ ?
- Authentication-results: sourceware.org; auth=none
- References: <20150414052030 dot GE8601 at tsaunders-iceball dot corp dot tor1 dot mozilla dot com> <CAFiYyc0RydCJhmSdB6_uDY+SpTAYC2RN_d17bdZR=ug7ThFN2w at mail dot gmail dot com>
On Tue, Apr 14, 2015 at 10:46:19AM +0200, Richard Biener wrote:
> On Tue, Apr 14, 2015 at 7:20 AM, Trevor Saunders <email@example.com> wrote:
> > Hi!
> > To be clear I only want to talk about gcc/**/*.c but *not* testsuite/
> > The Question of changing from .c to a more standard C++ file extension
> > has come up a couple times. I believe its reasonable accurate to say
> > the consensus is moderately in favor of doing this at some point. The
> > biggest concern was of course being able to access pre rename history
> > easily. I know git will either handle this by default or with an option
> > depending on the command, and svn claims it can handle renames so we
> > should be good on that front. The other question was if we should wait
> > to do this at the same time as a reorganization of directory structure.
> > That was back in august 2013, about a year and a half ago, and we
> > haven't done it or really moved forward with a plan to do it. It seems
> > to me that if we do this part now we can then deal with moving files
> > into directories later piece by piece and not need to move everything at
> > once. If we want to go ahead with renaming we should pick a time, I
> > think some people have advanced the idea of doing it just after a
> > branch, on the other hand last year we held off on the big gimple
> > refactoring until after the branch had released a .1.
> > thoughts?
> I see no value in doing this but making branch maintainance awkward.
I think its mostly valuable to cause less confusion of new people, and
though it is a simpler thing every little thing can be the thing that
breaks the cammel's back. Yes its not all that hard to configure
editors and what not to handle it properly, but every new person needs
to do it, and looking up configuration options takes time that can more
profitably be spent.
That said keeping backports as easy as possible is also certainly
important. I'm curious why renames hurt doing backports, I'm pretty
confident git cherry-pick will handle it for you, and if you like patch
files for some reason I'd think its easy to fix up with sed though
running that for each backport by hand would get a little old.
> > Trev