<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'><div>For now we aren't using autotools. I remain on the fence.</div><div><br></div><div><br></div><div>I want some of what they do, but they really are fairly ugly and slow and overkill.</div><div>I kinda want some other small portable scripting language.</div><div>The way they find the C compiler is pretty simple really.</div><div>Maybe python. Embedding it and adding functions?</div><div><br></div><div><br></div><div>I wonder about the value of much of the cm3 system.</div><div>Like, maybe quake would be better off replaced with Python?</div><div><br></div><div><br></div><div>libtool supports more systems than our config files, but is also</div><div>kinda ugly/overkill/slow and somewhat philosophically poor.</div><div>For example, the fact that they default to compiling everything twice,</div><div>pic and non-pic, bothers me. Surely it is not worth a) the double time</div><div>to build b) the slight loss of security in executables.</div><div>All code should just be pic.</div><div>They do make it an option, but when people foist that default decision</div><div>on the masses, it makes me wonder.</div><div>Apple has no such modes.</div><div>Windows has no such modes (though Windows doesn't do quite</div><div>what I want either).</div><div><br></div><div><br></div><div>In particular, I want someone else to</div><div> - find C and C++ compiler -- but what autotools does here is pretty simple </div><div><br></div><div> - pick out int8, int16, int32, int64 for me, with greater portability to older and newer systems </div><div> -- but there is inttypes.h on most systems anyway</div><div><br></div><div> - figure out how to link -- for static there is just one portable way (I adjusted</div><div> the config files recently), but for shared, libtool or cmake do it better?easier?</div><div><br></div><div> - generate portable makefiles for bootstrapping (or for regular building?) </div><div> Or just GNU makefiles? That is one some guidance I've seen -- give up on portable makefiles</div><div> and just use GNU make.</div><div><br></div><div><br></div><div>cmake??</div><div><br></div><div><br></div><div><br></div><div>I don't want to lose the fine grained incrementality the integrated builder has,</div><div>but it is tempting to make the system just generate makefiles.</div><div><br></div><div>I wonder which parts of the system are worth maintaining, vs. giving in to the larger</div><div>ecosystem of stuff being maintained for us.</div><div><br></div><div>cm3 is ahead of its time for 20 years ago but these days seems largely redundant.</div><div>Perhaps we can/should whittle it down to a more unique and worthwhile core?</div><div>I don't know.</div><div><br></div><div> - Jay<br><br></div><div>> Date: Tue, 1 Sep 2015 17:08:58 +0000<br>> From: microcode@zoho.com<br>> To: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] gcc vs. g++ in config files?<br>> <br>> Since you or somebody else mentioned autotools, I think the way this is<br>> normally handled is for the script to use cc or CC and it expects you to<br>> set those values in your shell to whatever compiler you want to use.<br>> <br>> On Tue, Sep 01, 2015 at 05:00:07PM +0000, Jay K wrote:<br>> > Sorry, this merits more discussion.<br>> > <br>> > - There are at least three ways compilers chose between C and C++.<br>> > <br>> > invocation name: gcc vs. g++, lowercase cc vs. uppercase CC<br>> > I think clang vs. clang++.<br>> > Visual C++ only has one invocation: cl<br>> > Source file extension: .c vs. .cpp, .cxx, .cc, .C, etc.This is very common with Visual C++.<br>> > Command line switches:<br>> > gcc -x c++ <br>> > clang -x C++<br>> > cl -Tc means next source file is C<br>> > -TC means all are C<br>> > -Tp means next is C++<br>> > -TP means all are C++<br>> > We'd have to read up on others.<br>> > <br>> > One of the combinations implemented by gcc is deprecated by clang.<br>> > I think clang++ foo.c. And, actually g++ foo.c (Apple installs clang as gcc).<br>> > So I switched to use -x c++.<br>> > <br>> > "cpp" is ambiguous between C preprocessor and C++.<br>> > "cxx" is often therefore used to indicate C++. x is a rotated +.<br>> > We could have config files specify SYSTEM_CC and SYSTEM_CXX.<br>> > And we could have functions compile_c and compile_cxx. <br>> > We could have builder c_source("foo") probe for foo.c, and foo.cpp, maybe<br>> > others, error if there are multiple, and chose compile_c vs. compile_cxx.<br>> > Or compile_c could chose based on the extension.<br>> > <br>> > In any case, makes changes to the C backend path, and in the llvm binding/backend<br>> > directories should be easy. We don't *have* to change the meanings everywhere<br>> > to effect them. I do not actually intend to rewrite all of our little bits<br>> > of C using C++ specific features. But the LLVM stuff uses C++ and the C backend<br>> > imho ought to.<br>> > <br>> > - Jay<br>> > <br>> > <br>> > <br>> > <br>> > From: jay.krell@cornell.edu<br>> > To: m3devel@elegosoft.com<br>> > Date: Tue, 1 Sep 2015 16:28:10 +0000<br>> > Subject: [M3devel] gcc vs. g++ in config files?<br>> > <br>> > <br>> > <br>> > <br>> > 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.<br>> > <br>> > 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.<br>> > <br>> > - Jay<br>> > <br>> > <br>> > <br>> > _______________________________________________<br>> > M3devel mailing list<br>> > M3devel@elegosoft.com<br>> > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel <br>> <br>> > _______________________________________________<br>> > M3devel mailing list<br>> > M3devel@elegosoft.com<br>> > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel<br>> <br>> <br>> -- <br>> <br>> _______________________________________________<br>> M3devel mailing list<br>> M3devel@elegosoft.com<br>> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel<br></div> </div></body>
</html>