This is the mail archive of the 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: is it time to mass change from .c to .cc in gcc/ ?

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
in libiberty.

There is no need to wait for reorganization to at least create a list of
such support data structures and functions (something like this: 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).

    Mikhail Maltsev

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