[M3devel] main in C or not?

[Jay K]

Hm. Interesting subtle angle you point out.
I have seen very few systems with ld but not cc. e.g. OLPC default install.
My HP-UX/hppa machine came with only a K&R cc.
Irix might have come with no official cc, but hunting around I found one that worked well enough to build gcc.
AIX maybe also.
We could potentially call ld directly.
  But in general I don't write the configuration files that way, they run cc for linking.
*.c is used a bunch in m3core but not much else.


On the other hand:
  cc is fairly ubiquitous.
  We have a "plan" for a "new distribution format" that will require cc -- users will build more of the
   system. Though we'll still provide binaries for some systems.


I'm *really* interested in a C-generating backend, which will subsume this.
Except perhaps systems like NT386, and maybe we'll expand that set.
I'm becoming increasingly frustrated with the gcc backend.


I can compromise and leave the code in m3linker, but I still like the change in cm3 where the configuration
is ignored.


I'll still go ahead and make the C code typesafe via ANSI prototypes.
  (potentially breaking HP-UX/hppa, but when I get back to that system I'll probably #ifdef
all the breakage, or require an ANSI compiler such as gcc; I assume nobody really
cares about K&R).


 Generating main in C seems to help some platforms, e.g. SOLgnu, SOLsun, SPARC32_LINUX,
but I admit I didn't fully debug these. And then, removing variations among configurations, I like.
But that can be achieved via the small change for now and leaving the support in.


 - Jay

> Date: Mon, 23 Aug 2010 13:57:01 +0200
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] main in C or not?
> 
> Quoting Jay K <jay.krell at cornell.edu>:
> 
> > There has long been a configuration variable: MAIN_IN_C.
> >
> > I propose that main always be in C. I made that so already, a small change.
> >
> > I further propose that the support for main to not be in C be removed.
> >
> > "Not in C" is "generating it via the backend", directly an .obj for NT386, or
> > going through the gcc backend for Posix.
> >
> > Furthermore, I'll cleanup the C to be more typesafe by using ANSI C.
> >
> > I have this change about ready.
> >
> > I don't think avoiding C is valuable and I'd rather have fewer   
> > configuration variables.
> > Pick one approach that works reasonably always.
> 
> This requires that every user must have a C compiler in addition to
> cm3. I thought the default was not to generate C, and just require
> a C compiler for special runtime support.
> 
> I'm not sure if this really a valid argument for the systems we support
> though, as we also need a system linker, and that is probably bundled with
> the C compiler in a development package.
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>                 Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>     http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100823/a7843995/attachment-0002.html>