C++ conversion? Why still .c (not .cc) files and CC (not CXX) in Makefile.in?
Hello All,
Sorry for such a stupid question, but assuming that the GCC trunk (e.g. svn rev
190745)
did already switch (during my holidays, so I did not follow that) to C++
per http://gcc.gnu.org/ml/gcc/2012-08/msg00165.html message, why are files
under gcc/ still keeping a .c (not a .cc) extension
(for example gcc/gimple-fold.c is not renamed to gcc/gimple-fold.cc), and why
does
gcc/Makefile.in still have more $(CC) than $(CXX)?
Or is the case that when building gcc the CC make variable
is always a true C++ compiler (e.g. some g++)?
Or do we have a rule than any file using C++ specific feature
should be renamed from *.c to *.cc at the moment the C++ feature goes inside?
(i'm trying to merge trunk back into MELT branch)
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: C++ conversion? Why still .c (not .cc) files and CC (not CXX) in Makefile.in?
On Tue, Aug 28, 2012 at 6:21 AM, Basile Starynkevitch wrote: > > Sorry for such a stupid question, but assuming that the GCC trunk (e.g. svn > rev 190745) > did already switch (during my holidays, so I did not follow that) to C++ > per http://gcc.gnu.org/ml/gcc/2012-08/msg00165.html message, why are files > under gcc/ still keeping a .c (not a .cc) extension > (for example gcc/gimple-fold.c is not renamed to gcc/gimple-fold.cc), and why > does > gcc/Makefile.in still have more $(CC) than $(CXX)? Probably we should change the file names at some point, with some large number of svn mv commands. It's not really a big deal though. In gcc/Makefile.in, most compilations are done using $(COMPILER). That has been true for some time. I see hardly any instances of $(CC) or $(CXX) in gcc/Makefile.in. > Or is the case that when building gcc the CC make variable > is always a true C++ compiler (e.g. some g++)? No, $(CC) is still a C compiler. > Or do we have a rule than any file using C++ specific feature > should be renamed from *.c to *.cc at the moment the C++ feature goes inside? We do not have such a rule and I would not recommend it. I think we should rename all the files at once at some point. Ian
Re: C++ conversion? Why still .c (not .cc) files and CC (not CXX) in Makefile.in?
Hi, On Tue, 28 Aug 2012, Ian Lance Taylor wrote: > > Or do we have a rule than any file using C++ specific feature should > > be renamed from *.c to *.cc at the moment the C++ feature goes inside? > > We do not have such a rule and I would not recommend it. I think we > should rename all the files at once at some point. That has implications on things like svn blame file.cc@somerevision in case somerevision was before that rename. So I'm not sure we should rename the files. I see disadvantages but no real advantages. Ciao, Michael.
Re: C++ conversion? Why still .c (not .cc) files and CC (not CXX) in Makefile.in?
On Tue, Aug 28, 2012 at 6:45 AM, Michael Matz wrote: > > On Tue, 28 Aug 2012, Ian Lance Taylor wrote: > >> > Or do we have a rule than any file using C++ specific feature should >> > be renamed from *.c to *.cc at the moment the C++ feature goes inside? >> >> We do not have such a rule and I would not recommend it. I think we >> should rename all the files at once at some point. > > That has implications on things like > svn blame file.cc@somerevision > in case somerevision was before that rename. So I'm not sure we should > rename the files. I see disadvantages but no real advantages. Doesn't svn blame look through an svn mv? Even if it does not, I agree that this is a disadvantage but not a major one. I use svn blame fairly often to track down the source of changes, and I inevitably have to go through several iterations to get past random changes. The advantage to renaming the files is also a minor one. It's less surprising to newcomers, and we automatically get the right processing from tools like emacs, tags, etc. Ian
Re: C++ conversion? Why still .c (not .cc) files and CC (not CXX) in Makefile.in?
On Aug 28, 2012, at 9:45 AM, Michael Matz wrote: > Hi, > > On Tue, 28 Aug 2012, Ian Lance Taylor wrote: > >>> Or do we have a rule than any file using C++ specific feature should >>> be renamed from *.c to *.cc at the moment the C++ feature goes inside? >> >> We do not have such a rule and I would not recommend it. I think we >> should rename all the files at once at some point. > > That has implications on things like > svn blame file.cc@somerevision > in case somerevision was before that rename. So I'm not sure we should > rename the files. I see disadvantages but no real advantages. True, that particular syntax doesn't work, but "svn blame file.cc -r somerevision" does -- because that command identifies the object to operate on in the namespace of the current (head) revision, and then examines the state of that object back in the requested revision. paul
Re: C++ conversion? Why still .c (not .cc) files and CC (not CXX) in Makefile.in?
On Tue, Aug 28, 2012 at 8:45 AM, Michael Matz wrote: > Hi, > > On Tue, 28 Aug 2012, Ian Lance Taylor wrote: > >> > Or do we have a rule than any file using C++ specific feature should >> > be renamed from *.c to *.cc at the moment the C++ feature goes inside? >> >> We do not have such a rule and I would not recommend it. I think we >> should rename all the files at once at some point. > > That has implications on things like > svn blame file.cc@somerevision > in case somerevision was before that rename. So I'm not sure we should > rename the files. I see disadvantages but no real advantages. *New* files should probably get the canonical extensions (e.g. .cc), but I don't see much being accomplished by mass renaming existing. I would rather see their *contents* improved first. -- Gaby
gcc trunk target libraries do not build on Darwin 12.1
I am having trouble building the trunk om Mac OS X 10.8.1 (Darwin 12.1.0). Configuring target libraries fails with the following error (e.g. libatomic): configure:3477: checking for C compiler default output file name configure:3499: /eng/upc/dev/nenad/gcc-trunk/bld/./gcc/xgcc -B/eng/upc/dev/nenad/gcc-trunk/bld/./gcc/ -B/usr/local/x86_64-apple-darwin12.1.0/bin/ -B/usr/local/x86_64-apple-darwin12.1.0/lib/ -isystem /usr/local/x86_64-apple-darwin12.1.0/include -isystem /usr/local/x86_64-apple-darwin12.1.0/sys-include-g -O2 conftest.c >&5 Undefined symbols for architecture x86_64: "start", referenced from: -u command line option ld: symbol(s) not found for architecture x86_64 collect2: error: ld returned 1 exit status The above uses the following link lines: /eng/upc/dev/nenad/gcc-trunk/bld/./gcc/collect2 -dynamic -arch x86_64 -macosx_version_min 10.8.1 -weak_reference_mismatches non-weak -o a.out -L/eng/upc/dev/nenad/gcc-trunk/bld/./gcc /var/folders/z7/83zx0wdj4cx644rg7p7kgwb8gn/T//cc6kpstu.o -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lSystem -v -idsym -dsym collect2 version 4.8.0 20120828 (experimental) /eng/upc/dev/nenad/gcc-trunk/bld/./gcc/collect-ld -dynamic -arch x86_64 -macosx_version_min 10.8.1 -weak_reference_mismatches non-weak -o a.out -L/eng/upc/dev/nenad/gcc-trunk/bld/./gcc /var/folders/z7/83zx0wdj4cx644rg7p7kgwb8gn/T//cc6kpstu.o -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lSystem -v Test links if I add "-lcrt1.o" on the command line. I have the latest Xcode loaded and my Mac is up to date. Any idea? Nenad
