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: Mikhail Maltsev <maltsevm at gmail dot com>
- To: Trevor Saunders <tbsaunde at tbsaunde dot org>, Richard Biener <richard dot guenther at gmail dot com>
- Cc: GCC Development <gcc at gcc dot gnu dot org>
- Date: Wed, 15 Apr 2015 12:53:22 +0300
- 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> <20150415000911 dot GA30215 at tsaunders-iceball dot corp dot tor1 dot mozilla dot com>
On 15.04.2015 3:09, Trevor Saunders wrote:
> On Tue, Apr 14, 2015 at 10:46:19AM +0200, Richard Biener wrote:
>> 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.
Well, for me, as a newcomer, configuring the editor and getting used to
non-standard file extensions was, perhaps, one of the easiest parts (but
yes, that's a bit confusing).
You mentioned that you are planning to do reorganization of the
directory structure. That would be really helpful. LLVM has two separate
directories for utility classes, functions and custom datatypes
(llvm/include/llvm/ADT and llvm/include/llvm/Support). In GCC all those
useful things are scattered among 771 files in gcc directory, some are
There is no need to wait for reorganization to at least create a list of
such support data structures and functions (something like this:
http://llvm.org/docs/ProgrammersManual.html). The good thing is that we
already have excellent documentation for some of them in source code
(for example vec.h and is-a.h), but we are missing the list.
> 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.
IIRC, SVN can dump the whole repository and import it again. So, if it's
really desired, it's possible to rename the files "in the past" without
loosing the history by filtering the dump (but git mirror must be
rebuilt in this case).