Re: New file extension
> Martin Jambor : > Well, IIRC mostly worries about history. SVN claims to be able to > track history of renamed files but I use the git mirror now and I > wonder what the history would show there. I would consider it very > unfortunate if 'git blame' did not show the .c era history of the > renamed files. But maybe it would just work. It depends on how the rename if done. If a file is added that has the exact same SHA1 hash as a file with a different path, then git assumes that the new file is a copy of the other file, and blame and the log history can be made to follow the history beyond the copy. Actually "git blame" always follow the history across renames, and "git log" needs the "--follow" option, or a config setting, to do so. I have no idea what git-svn (or whatever) will do when it comes to an svn rename, but it would make sense if it replicated it by a commit that does a git rm of the file in the old location, and a git add of the file in the new location. If the svn rename also changes the renamed file, then things get trickier... git-svn would have to split that commit into two.
Re: New file extension
Hi,
On Tue, Jul 30, 2013 at 11:07:52AM -0500, Gabriel Dos Reis wrote:
> On Tue, Jul 30, 2013 at 7:28 AM, Martin Jambor wrote:
>
> > As far as newbies are concerned, I think that grasping that .c files
> > are C++ files is one of the easy things to learn about GCC compared to
> > other necessary knowledge (which is something we should work on).
>
> One more oddities compared to standard practice.
>
> > If the problem is that your emacs opens gcc files in C mode instead of
> > C++, add this to your .emacs file:
> >
> > (add-to-list 'auto-mode-alist '("gcc/.+\\.[ch]\\'" . c++-mode))
>
> More oddities: we assume Emacs, and we want people to add those things.
> Are we sure we are worrying about newcomers, or just fighting to preserve
> the way things used to be 20 years?
I am quite sure. You removed part of my email where I said I would
not mind mass renaming at all if git history was still easily usable.
This is not because I am some sort of crazy conservative, it is
because I use the history very often and I believe I am not alone.
Moreover, after reading Andrew's email in which he outlined a mass
renaming as a part of re-architecting gcc, I believe that waiting for
that to happen and having it happen is the best course of action (even
regardless of inconveniences with git history because that is not
going to be renaming for the sake of renaming but a substantial
change, worth doing nevertheless, or at least I hope so).
In the meantime, people can reconfigure their editor as I do with
emacs.
I still think that mixing C++ .c files and .cc files is silly and more
confusing than what we have now. However, I can live with it.
As far as newcomers are concerned, I have joined GCC only about 6
years ago so I am still quite new and still remember my earliest days.
>From my experience, the real obstacles are the tough issues to
overcome (like when you have an ICE in expr.c and there is no way you
can understand what is even going on there, let alone why it ICEs),
certainly not a number of small oddities. If we really want to help
newcomers, we have to concentrate on the difficult stuff. The simple
things usually do not really matter.
Furthermore, if we do a svn rename here and there, _mechanically_ turn
a struct into a class or a macro into a template (you noted I stressed
the word mechanically, right?) or remove some other small oddity at
the expense of making life of core gcc developers more difficult, the
newcomers will not even notice and the overall outcome will be
negative. This is not trying to keep things as they were 20 years
ago, this is saying we should only make changes that make sense. And
personally, I hope I will not only welcome such changes, but also be
able to help with them.
Martin
Re: New file extension
On Tue, Jul 30, 2013 at 7:42 AM, Marek Polacek wrote: > On Tue, Jul 30, 2013 at 08:35:12AM -0400, Andrew MacLeod wrote: >> On 07/30/2013 08:27 AM, Marek Polacek wrote: >> >On Tue, Jul 30, 2013 at 07:13:22AM -0400, Diego Novillo wrote: >> >>On Tue, Jul 30, 2013 at 5:04 AM, Marek Polacek wrote: >> >>>On Mon, Jul 29, 2013 at 10:08:26PM +0200, Martin Jambor wrote: >> I do not care very much but I disagree. Having some files with .c >> suffix and some with .cc suffix would imply some sort of difference >> where there is going to be none. >> >>>Yeah -- this sort of discrepancy I don't like either. In gcc/, we >> >>>have 362 .c files and 0 .cc files, so every new .cc file will step out >> >>>of line... That might be pain for people who are used to do >> >>>'grep foo gcc/*.c' and suchlike. >> >>Any issues with doing a mass rename then? >> I'd suggest waiting for a mass rename until the next stage 1... (or >> stage 0.9 :-) I will want to mass rename a lot of the files (ie, a >> lot of tree-* will lose the tree- prefix), and I think we'll be >> moving directory structures around as well... and some include files >> will be split up... etc. etc.Seems like a logical time to change >> extensions too. >> >> My point is, why go through the pain of changing a bunch of files >> now when we are probably going to do it again within a year. > > On second thought, yes, waiting for mass rename sounds better than to > add one .cc file... > > Marek I am skeptical we would be able to implement mass renaming. -- Gaby
Re: New file extension
On Tue, Jul 30, 2013 at 7:28 AM, Martin Jambor wrote:
> As far as newbies are concerned, I think that grasping that .c files
> are C++ files is one of the easy things to learn about GCC compared to
> other necessary knowledge (which is something we should work on).
One more oddities compared to standard practice.
> If the problem is that your emacs opens gcc files in C mode instead of
> C++, add this to your .emacs file:
>
> (add-to-list 'auto-mode-alist '("gcc/.+\\.[ch]\\'" . c++-mode))
More oddities: we assume Emacs, and we want people to add those things.
Are we sure we are worrying about newcomers, or just fighting to preserve
the way things used to be 20 years?
Re: New file extension
On Tue, Jul 30, 2013 at 6:51 AM, Joseph S. Myers wrote: > On Tue, 30 Jul 2013, Basile Starynkevitch wrote: > >> I think it is a good idea now (except perhaps for the very few source files >> which could still be compiled by a plain C, not C++, compiler; maybe we >> don't have anymore them...). > > gcov-io.c is C code used for both host and target (one of the remaining > bits of target library source not moved out of the gcc/ directory because > of the complications of the dual way it's used), but it's used for the > host (and built as C++ when so used) via #include in other .c files rather > than being built directly. This is a good example of what I meant originally by "unless they are meant to be processed by a C compiler." > Various Ada runtime library files are also .c under gcc/ada - in general, > I'm not sure which .c files there are used as C, C++ or both, and which > are used for host, target or both; that would require careful > investigation for any renaming. Indeed. -- Gaby
Re: New file extension
On Tue, Jul 30, 2013 at 4:04 AM, Marek Polacek wrote: > On Mon, Jul 29, 2013 at 10:08:26PM +0200, Martin Jambor wrote: >> I do not care very much but I disagree. Having some files with .c >> suffix and some with .cc suffix would imply some sort of difference >> where there is going to be none. > > Yeah -- this sort of discrepancy I don't like either. In gcc/, we > have 362 .c files and 0 .cc files, so every new .cc file will step out > of line... Any thing *new* steps out of line for someone. Putting C++ programs in .c file is out of line for most people, including the newcomers that people worry about. For many tools, including editors, .c is a C file, not a C++ file, so you don't get the benefit of working with a C++ program. > That might be pain for people who are used to do > 'grep foo gcc/*.c' and suchlike. > > Marek
Re: New file extension
On Tue, Jul 30, 2013 at 6:13 AM, Diego Novillo wrote: > On Tue, Jul 30, 2013 at 5:04 AM, Marek Polacek wrote: >> On Mon, Jul 29, 2013 at 10:08:26PM +0200, Martin Jambor wrote: >>> I do not care very much but I disagree. Having some files with .c >>> suffix and some with .cc suffix would imply some sort of difference >>> where there is going to be none. >> >> Yeah -- this sort of discrepancy I don't like either. In gcc/, we >> have 362 .c files and 0 .cc files, so every new .cc file will step out >> of line... That might be pain for people who are used to do >> 'grep foo gcc/*.c' and suchlike. > > Any issues with doing a mass rename then? I didn't want to open of the can of worm where would find any reason to make this happen. There might be genuine concerns with people doing work on branches. -- Gaby
Re: New file extension
On Mon, Jul 29, 2013 at 3:08 PM, Martin Jambor wrote: > On Sat, Jul 27, 2013 at 08:42:16AM -0500, Gabriel Dos Reis wrote: >> Hi, >> >> I would like to suggest that new implementation files have >> the '.cc' extension, unless they are meant to be processed >> with a C compiler. (I am not proposing wholesale renaming.) >> > > I do not care very much but I disagree. Having some files with .c > suffix and some with .cc suffix would imply some sort of difference > where there is going to be none. Much more confusing than C++ > compiled .c files, especially to newcomers, I suppose... and I though > we cared about them, that's the reason why I'm writing this email. I > will not be surprised by this myself, so I can live with it. > > Martin We do care about newcomers, but with all these new projects for refactoring, rewrites going on, I think you are worrying about things that may start "big" now but will be vanishing as the GCC project lives on. -- Gaby
Re: New file extension
On Tue, Jul 30, 2013 at 08:35:12AM -0400, Andrew MacLeod wrote: > On 07/30/2013 08:27 AM, Marek Polacek wrote: > >On Tue, Jul 30, 2013 at 07:13:22AM -0400, Diego Novillo wrote: > >>On Tue, Jul 30, 2013 at 5:04 AM, Marek Polacek wrote: > >>>On Mon, Jul 29, 2013 at 10:08:26PM +0200, Martin Jambor wrote: > I do not care very much but I disagree. Having some files with .c > suffix and some with .cc suffix would imply some sort of difference > where there is going to be none. > >>>Yeah -- this sort of discrepancy I don't like either. In gcc/, we > >>>have 362 .c files and 0 .cc files, so every new .cc file will step out > >>>of line... That might be pain for people who are used to do > >>>'grep foo gcc/*.c' and suchlike. > >>Any issues with doing a mass rename then? > I'd suggest waiting for a mass rename until the next stage 1... (or > stage 0.9 :-) I will want to mass rename a lot of the files (ie, a > lot of tree-* will lose the tree- prefix), and I think we'll be > moving directory structures around as well... and some include files > will be split up... etc. etc.Seems like a logical time to change > extensions too. > > My point is, why go through the pain of changing a bunch of files > now when we are probably going to do it again within a year. On second thought, yes, waiting for mass rename sounds better than to add one .cc file... Marek
Re: New file extension
On 07/30/2013 08:27 AM, Marek Polacek wrote: On Tue, Jul 30, 2013 at 07:13:22AM -0400, Diego Novillo wrote: On Tue, Jul 30, 2013 at 5:04 AM, Marek Polacek wrote: On Mon, Jul 29, 2013 at 10:08:26PM +0200, Martin Jambor wrote: I do not care very much but I disagree. Having some files with .c suffix and some with .cc suffix would imply some sort of difference where there is going to be none. Yeah -- this sort of discrepancy I don't like either. In gcc/, we have 362 .c files and 0 .cc files, so every new .cc file will step out of line... That might be pain for people who are used to do 'grep foo gcc/*.c' and suchlike. Any issues with doing a mass rename then? I'd suggest waiting for a mass rename until the next stage 1... (or stage 0.9 :-) I will want to mass rename a lot of the files (ie, a lot of tree-* will lose the tree- prefix), and I think we'll be moving directory structures around as well... and some include files will be split up... etc. etc.Seems like a logical time to change extensions too. My point is, why go through the pain of changing a bunch of files now when we are probably going to do it again within a year. Andrew
Re: New file extension
> Various Ada runtime library files are also .c under gcc/ada - in general, > I'm not sure which .c files there are used as C, C++ or both, and which > are used for host, target or both; that would require careful > investigation for any renaming. The C files directly under ada/ cannot be renamed since they are meant to be compiled by the C compiler; only the ones under ada/gcc-interface can. -- Eric Botcazou
Re: New file extension
On Tue, Jul 30, 2013 at 11:51:35AM +, Joseph S. Myers wrote:
> On Tue, 30 Jul 2013, Basile Starynkevitch wrote:
>
> > I think it is a good idea now (except perhaps for the very few source files
> > which could still be compiled by a plain C, not C++, compiler; maybe we
> > don't have anymore them...).
>
> gcov-io.c is C code used for both host and target (one of the remaining
> bits of target library source not moved out of the gcc/ directory because
> of the complications of the dual way it's used), but it's used for the
> host (and built as C++ when so used) via #include in other .c files rather
> than being built directly.
>
> Various Ada runtime library files are also .c under gcc/ada - in general,
> I'm not sure which .c files there are used as C, C++ or both, and which
> are used for host, target or both; that would require careful
> investigation for any renaming.
Ok. Then we could at leat rename to *.cc those files which are obviously
directly
using C++ features (e.g. the class or virtual C++ keywords).
Maybe these files should before renaming have
#ifndef __cplusplus
#error should be compiled as C++ code
#endif
??
Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: New file extension
Hi,
On Tue, Jul 30, 2013 at 07:13:22AM -0400, Diego Novillo wrote:
> On Tue, Jul 30, 2013 at 5:04 AM, Marek Polacek wrote:
> > On Mon, Jul 29, 2013 at 10:08:26PM +0200, Martin Jambor wrote:
> >> I do not care very much but I disagree. Having some files with .c
> >> suffix and some with .cc suffix would imply some sort of difference
> >> where there is going to be none.
> >
> > Yeah -- this sort of discrepancy I don't like either. In gcc/, we
> > have 362 .c files and 0 .cc files, so every new .cc file will step out
> > of line... That might be pain for people who are used to do
> > 'grep foo gcc/*.c' and suchlike.
>
> Any issues with doing a mass rename then?
>
Well, IIRC mostly worries about history. SVN claims to be able to
track history of renamed files but I use the git mirror now and I
wonder what the history would show there. I would consider it very
unfortunate if 'git blame' did not show the .c era history of the
renamed files. But maybe it would just work.
I think that proponents of this idea should make some experiments
along these lines to estimate the cost. OTOH, I think the time can be
spent better (and that is also the reason why I will not fight about
this beyond writing this message).
As far as newbies are concerned, I think that grasping that .c files
are C++ files is one of the easy things to learn about GCC compared to
other necessary knowledge (which is something we should work on).
If the problem is that your emacs opens gcc files in C mode instead of
C++, add this to your .emacs file:
(add-to-list 'auto-mode-alist '("gcc/.+\\.[ch]\\'" . c++-mode))
Even after a rename you would have to do something like that for the
.h files anyway.
Thanks,
Martin
Re: New file extension
On Tue, Jul 30, 2013 at 07:13:22AM -0400, Diego Novillo wrote: > On Tue, Jul 30, 2013 at 5:04 AM, Marek Polacek wrote: > > On Mon, Jul 29, 2013 at 10:08:26PM +0200, Martin Jambor wrote: > >> I do not care very much but I disagree. Having some files with .c > >> suffix and some with .cc suffix would imply some sort of difference > >> where there is going to be none. > > > > Yeah -- this sort of discrepancy I don't like either. In gcc/, we > > have 362 .c files and 0 .cc files, so every new .cc file will step out > > of line... That might be pain for people who are used to do > > 'grep foo gcc/*.c' and suchlike. > > Any issues with doing a mass rename then? If various svn/git blame/log's would work, then I'm fine with it. It's been discussed on gcc@ at some point; I don't remember any major (dis)advantages. Ok, I'll rename my new .c files to .cc. Marek
Re: New file extension
On Tue, 30 Jul 2013, Basile Starynkevitch wrote: > I think it is a good idea now (except perhaps for the very few source files > which could still be compiled by a plain C, not C++, compiler; maybe we > don't have anymore them...). gcov-io.c is C code used for both host and target (one of the remaining bits of target library source not moved out of the gcc/ directory because of the complications of the dual way it's used), but it's used for the host (and built as C++ when so used) via #include in other .c files rather than being built directly. Various Ada runtime library files are also .c under gcc/ada - in general, I'm not sure which .c files there are used as C, C++ or both, and which are used for host, target or both; that would require careful investigation for any renaming. -- Joseph S. Myers jos...@codesourcery.com
Re: New file extension
On Tue, Jul 30, 2013 at 07:13:22AM -0400, Diego Novillo wrote:
> On Tue, Jul 30, 2013 at 5:04 AM, Marek Polacek wrote:
> > On Mon, Jul 29, 2013 at 10:08:26PM +0200, Martin Jambor wrote:
> >> I do not care very much but I disagree. Having some files with .c
> >> suffix and some with .cc suffix would imply some sort of difference
> >> where there is going to be none.
> >
> > Yeah -- this sort of discrepancy I don't like either. In gcc/, we
> > have 362 .c files and 0 .cc files, so every new .cc file will step out
> > of line... That might be pain for people who are used to do
> > 'grep foo gcc/*.c' and suchlike.
>
> Any issues with doing a mass rename then?
I think it is a good idea now (except perhaps for the very few source files
which could still be compiled by a plain C, not C++, compiler; maybe we
don't have anymore them...).
FWIW, when compiling GCC trunk with Clang3.4 (i.e. on Debian/Sid+Experimental)
I am getting warnings about *.c being a C++ file.
And I think newbies are distracted also by .c files being in C++ (not to mention
emacs or other editors being possibly confused).
So I am in favor of a massive renaming. (But please do it in one single huge
svn commit).
Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: New file extension
On Tue, Jul 30, 2013 at 5:04 AM, Marek Polacek wrote: > On Mon, Jul 29, 2013 at 10:08:26PM +0200, Martin Jambor wrote: >> I do not care very much but I disagree. Having some files with .c >> suffix and some with .cc suffix would imply some sort of difference >> where there is going to be none. > > Yeah -- this sort of discrepancy I don't like either. In gcc/, we > have 362 .c files and 0 .cc files, so every new .cc file will step out > of line... That might be pain for people who are used to do > 'grep foo gcc/*.c' and suchlike. Any issues with doing a mass rename then? Diego.
Re: New file extension
On Mon, Jul 29, 2013 at 10:08:26PM +0200, Martin Jambor wrote: > I do not care very much but I disagree. Having some files with .c > suffix and some with .cc suffix would imply some sort of difference > where there is going to be none. Yeah -- this sort of discrepancy I don't like either. In gcc/, we have 362 .c files and 0 .cc files, so every new .cc file will step out of line... That might be pain for people who are used to do 'grep foo gcc/*.c' and suchlike. Marek
Re: New file extension
On Sat, Jul 27, 2013 at 08:42:16AM -0500, Gabriel Dos Reis wrote: > Hi, > > I would like to suggest that new implementation files have > the '.cc' extension, unless they are meant to be processed > with a C compiler. (I am not proposing wholesale renaming.) > I do not care very much but I disagree. Having some files with .c suffix and some with .cc suffix would imply some sort of difference where there is going to be none. Much more confusing than C++ compiled .c files, especially to newcomers, I suppose... and I though we cared about them, that's the reason why I'm writing this email. I will not be surprised by this myself, so I can live with it. Martin
Re: New file extension
On Mon, Jul 29, 2013 at 11:11 AM, Marek Polacek wrote: > On Sat, Jul 27, 2013 at 08:42:16AM -0500, Gabriel Dos Reis wrote: >> Hi, >> >> I would like to suggest that new implementation files have >> the '.cc' extension, unless they are meant to be processed >> with a C compiler. (I am not proposing wholesale renaming.) > > Oh, I suppose this applies to ubsan, yes. :-) -- Gaby
Re: New file extension
On Sat, Jul 27, 2013 at 08:42:16AM -0500, Gabriel Dos Reis wrote: > Hi, > > I would like to suggest that new implementation files have > the '.cc' extension, unless they are meant to be processed > with a C compiler. (I am not proposing wholesale renaming.) Oh, I suppose this applies to ubsan, e.g. (Haven't commited it to trunk yet, but so far the files still have the '.c' extension.) Will rename it then, though I like '.c' more ;). Marek
Re: New file extension
On Sat, Jul 27, 2013 at 9:42 AM, Gabriel Dos Reis wrote: > Hi, > > I would like to suggest that new implementation files have > the '.cc' extension, unless they are meant to be processed > with a C compiler. (I am not proposing wholesale renaming.) Agreed. Diego.
