<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
> I can compromise and leave the code in m3linker, but I still like the change in cm3 where the configuration<br> > is ignored.<br><br><br>Alternatively I can change cm3cfg.common.<br><br> - Jay<br><br><br><hr id="stopSpelling">From: jay.krell@cornell.edu<br>To: wagner@elegosoft.com; m3devel@elegosoft.com<br>Subject: RE: [M3devel] main in C or not?<br>Date: Mon, 23 Aug 2010 21:51:44 +0000<br><br>
<meta http-equiv="Content-Type" content="text/html; charset=unicode">
<meta name="Generator" content="Microsoft SafeHTML">
<style>
.ExternalClass .ecxhmmessage P
{padding:0px;}
.ExternalClass body.ecxhmmessage
{font-size:10pt;font-family:Tahoma;}
</style>
Hm. Interesting subtle angle you point out.<br>I have seen very few systems with ld but not cc. e.g. OLPC default install.<br>My HP-UX/hppa machine came with only a K&R cc.<br>Irix might have come with no official cc, but hunting around I found one that worked well enough to build gcc.<br>AIX maybe also.<br>We could potentially call ld directly.<br> But in general I don't write the configuration files that way, they run cc for linking.<br>*.c is used a bunch in m3core but not much else.<br><br><br>On the other hand:<br> cc is fairly ubiquitous.<br> We have a "plan" for a "new distribution format" that will require cc -- users will build more of the<br> system. Though we'll still provide binaries for some systems.<br><br><br>I'm *really* interested in a C-generating backend, which will subsume this.<br>Except perhaps systems like NT386, and maybe we'll expand that set.<br>I'm becoming increasingly frustrated with the gcc backend.<br><br><br>I can compromise and leave the code in m3linker, but I still like the change in cm3 where the configuration<br>is ignored.<br><br><br>I'll still go ahead and make the C code typesafe via ANSI prototypes.<br> (potentially breaking HP-UX/hppa, but when I get back to that system I'll probably #ifdef<br>all the breakage, or require an ANSI compiler such as gcc; I assume nobody really<br>cares about K&R).<br><br><br> Generating main in C seems to help some platforms, e.g. SOLgnu, SOLsun, SPARC32_LINUX,<br>but I admit I didn't fully debug these. And then, removing variations among configurations, I like.<br>But that can be achieved via the small change for now and leaving the support in.<br><br><br> - Jay<br><br>> Date: Mon, 23 Aug 2010 13:57:01 +0200<br>> From: wagner@elegosoft.com<br>> To: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] main in C or not?<br>> <br>> Quoting Jay K <jay.krell@cornell.edu>:<br>> <br>> > There has long been a configuration variable: MAIN_IN_C.<br>> ><br>> > I propose that main always be in C. I made that so already, a small change.<br>> ><br>> > I further propose that the support for main to not be in C be removed.<br>> ><br>> > "Not in C" is "generating it via the backend", directly an .obj for NT386, or<br>> > going through the gcc backend for Posix.<br>> ><br>> > Furthermore, I'll cleanup the C to be more typesafe by using ANSI C.<br>> ><br>> > I have this change about ready.<br>> ><br>> > I don't think avoiding C is valuable and I'd rather have fewer <br>> > configuration variables.<br>> > Pick one approach that works reasonably always.<br>> <br>> This requires that every user must have a C compiler in addition to<br>> cm3. I thought the default was not to generate C, and just require<br>> a C compiler for special runtime support.<br>> <br>> I'm not sure if this really a valid argument for the systems we support<br>> though, as we also need a system linker, and that is probably bundled with<br>> the C compiler in a development package.<br>> <br>> Olaf<br>> -- <br>> Olaf Wagner -- elego Software Solutions GmbH<br>> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany<br>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95<br>> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin<br>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<br>> <br> </body>
</html>