[M3devel] gcc vs. g++ in config files?

Jay K jay.krell at cornell.edu
Tue Sep 1 20:02:27 CEST 2015


For now we aren't using autotools. I remain on the fence.

I want some of what they do, but they really are fairly ugly and slow and overkill.I kinda want some other small portable scripting language.The way they find the C compiler is pretty simple really.Maybe python. Embedding it and adding functions?

I wonder about the value of much of the cm3 system.Like, maybe quake would be better off replaced with Python?

libtool supports more systems than our config files, but is alsokinda ugly/overkill/slow and somewhat philosophically poor.For example, the fact that they default to compiling everything twice,pic and non-pic, bothers me. Surely it is not worth a) the double timeto build b) the slight loss of security in executables.All code should just be pic.They do make it an option, but when people foist that default decisionon the masses, it makes me wonder.Apple has no such modes.Windows has no such modes (though Windows doesn't do quitewhat I want either).

In particular, I want someone else to  - find C and C++ compiler -- but what autotools does here is pretty simple 
  - pick out int8, int16, int32, int64 for me, with greater portability to older and newer systems        -- but there is inttypes.h on most systems anyway
  - figure out how to link -- for static there is just one portable way (I adjusted   the config files recently), but for shared, libtool or cmake do it better?easier?
  - generate portable makefiles for bootstrapping (or for regular building?)      Or just GNU makefiles? That is one some guidance I've seen -- give up on portable makefiles   and just use GNU make.

cmake??


I don't want to lose the fine grained incrementality the integrated builder has,but it is tempting to make the system just generate makefiles.
I wonder which parts of the system are worth maintaining, vs. giving in to the largerecosystem of stuff being maintained for us.
cm3 is ahead of its time for 20 years ago but these days seems largely redundant.Perhaps we can/should whittle it down to a more unique and worthwhile core?I don't know.
 - Jay

> Date: Tue, 1 Sep 2015 17:08:58 +0000
> From: microcode at zoho.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] gcc vs. g++ in config files?
> 
> Since you or somebody else mentioned autotools, I think the way this is
> normally handled is for the script to use cc or CC and it expects you to
> set those values in your shell to whatever compiler you want to use.
> 
> On Tue, Sep 01, 2015 at 05:00:07PM +0000, Jay K wrote:
> > Sorry, this merits more discussion.
> > 
> >  - There are at least three ways compilers chose between C and C++.
> > 
> >  invocation name: gcc vs. g++, lowercase cc vs. uppercase CC
> >   I think clang vs. clang++.
> >  Visual C++ only has one invocation: cl
> >  Source file extension: .c vs. .cpp, .cxx, .cc, .C, etc.This is very common with Visual C++.
> >  Command line switches:
> >   gcc -x c++ 
> >   clang -x C++
> >   cl -Tc means next source file is C
> >    -TC means all are C
> >    -Tp means next is C++
> >    -TP means all are C++
> > We'd have to read up on others.
> > 
> >  One of the combinations implemented by gcc is deprecated by clang.
> >  I think clang++ foo.c. And, actually g++ foo.c (Apple installs clang as gcc).
> >  So I switched to use -x c++.
> > 
> >  "cpp" is ambiguous between C preprocessor and C++.
> >  "cxx" is often therefore used to indicate C++. x is a rotated +.
> >  We could have config files specify SYSTEM_CC and SYSTEM_CXX.
> >  And we could have functions compile_c and compile_cxx. 
> >  We could have builder c_source("foo") probe for foo.c, and foo.cpp, maybe
> >  others, error if there are multiple, and chose compile_c vs. compile_cxx.
> >  Or compile_c could chose based on the extension.
> > 
> >  In any case, makes changes to the C backend path, and in the llvm binding/backend
> >  directories should be easy. We don't *have* to change the meanings everywhere
> >  to effect them. I do not actually intend to rewrite all of our little bits
> >  of C using C++ specific features. But the LLVM stuff uses C++ and the C backend
> >  imho ought to.
> > 
> >  - Jay
> > 
> > 
> > 
> > 
> > From: jay.krell at cornell.edu
> > To: m3devel at elegosoft.com
> > Date: Tue, 1 Sep 2015 16:28:10 +0000
> > Subject: [M3devel] gcc vs. g++ in config files?
> > 
> > 
> > 
> > 
> > I suggest we replace "gcc" with "g++".In all the config files (and in the bootstrap archives).And similar for Sun CC, and Visual C++ use -TP.
> > 
> > rationale: It will likely cleanup our LLVM stuff, which currently uses a custom Makefile and drops derived files into the src directory.  It will ease/allow using C++ exception handling in the C backend.  I've been using g++ for months/years on Darwin. counter-rationale: Not all C code is valid C++, and sometimes the meanings are different. I converted the coverage code only recently.
> > 
> >  - Jay
> > 
> >  		 	   		  
> > 
> > _______________________________________________
> > M3devel mailing list
> > M3devel at elegosoft.com
> > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel 		 	   		  
> 
> > _______________________________________________
> > M3devel mailing list
> > M3devel at elegosoft.com
> > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
> 
> 
> -- 
> 
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150901/9aba4b82/attachment-0002.html>


More information about the M3devel mailing list