[M3devel] building packages

[Jay K]

  > From: hendrik at topoi.pooq.com     > I wasn't using the CVS tree. I was using   
  > cm3-src-all-5.8.6-REL.tgz, downloaded from   
  
 cm3-src-all-5.8.6-REL.tgz really ought to work.     
 But I don't know.    
 I can try later.   
 
  
  
  > That's what I'll do. Is the current head in good   
  > enough shape?     I think so, but please try it, and we'll see.    
  I've actively using it lately (working on moving to gcc 4.6, making good progress)      
 
  > So you compile the gcc backend. Presumably cross-compile   
  > it if necessary. Does gcc on one platform also produce   
  > object code for another? Or does the script custom-pick   
  > the backend depending on the target platform?  
It works. Trust me. Try it.   Details:
 
  if you read m3cc/src/m3makefile, you see that "build_dir" is either "." or "../<host>-<target>"      "." is really host or target -- the same thing, for a native build.    cm3 automatically creates and cd's into it, rending it as just ".".     We configure gcc appropriately (--host, --target) and run the cm3cg by full path, as I recall.     We aren't cross-compiling gcc. We are building a cross-compiler.  
  The following is confusing, but makes sense once you get your head around it:  
  There are potentially up to 3 machines: "build", "host", "target".  
  "build" is the machine you are sitting on "now". The one you are building the compiler on.  
  The machine you are building the compiler on.    
  "host" is the machine that the resulting compiler will run on. It will "host" the compiler.    
  "target" is the machine that will run the compiler's output -- that the compiler will "target".       In common practise, all 3 are the same and things are nice and simple.  
    
  But it can be that any two of three are the same or that all three are the same.
    In the context of the Modula-3 build scripts, build and host are always the same.    
  
  When host and target are different, that is a cross compiler.
  When build and host are different, you are cross compiling the compiler.    
  When all three are different, you are cross compiling a cross compiler.  
  When build and target are the same but not equal to host, I don't know a term for that, I call it "cross back" -- you are     building a compiler that will run on a different system but which will produce code for the system you are building it on.  
  
     
  The challenge in various "cross " scenarios is having/getting the headers and libraries (libc) and linker and assembler,   
  and related, building libgcc2.   
  Often-times but not always, the GNU linker/assembler help.    
  Sometimes GNU libc helps.    
  But I for example haven't been able to build an ia64-linux toolset, due to the headers/libraries.  
  
  Building the C frontend/backend (and gcc driver for that matter) for build==host is actually always very easy.  
 
  
  If you program is just:
  int add(int a, int b) { return a + b }        and you have gcc source, it is easy to convert it to assembly for any target,
  without any headers/libraries/linker/assembler. That is all Modula-3 uses gcc for.    
  But throw in an #include <stdio.h> or try to link to anything, and you need a lot more.      In the Modula-3 system, how it was mostly structured at the start, and now, we cheat.  
  "final compilation/assembly/linking" can be deferred to the target system, which is  
  dependend upon to have a working native toolset. That is what my "bootstrap" archives do.
  That is what the "bootstrap" archives of olden times (circa 3.6/1996) did I believe. 
  Also quake was written in C back then.   
  Targeting something like iPhone/iPad doesn't fit...except that C cross tools are available  
  enough, so the same structuring works fine.  
  You typically just have to run different toplevel gcc/ld or add a switch like gcc -arch arm.      We also cheat these days in that where #include <stdio.h> (for C runtime/kernel) was needed, I rewrote the code in C.    This protects us from stdio.h changing or varying per-target. It was a big porting and maintenance and safety problem.    <windows.h> and <Xlib.h> we still clone in Modula-3. They don't change so much. But maybe we should    do something different there too.  
   Make some sense?      - Jay   		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120516/b84cf658/attachment-0002.html>