[M3devel] replace build system??

[Jay K]

Fair questions.

LINUXLIBC6 and I386_LINUX are the same really.
It should work to just rename a few files and change the string in the config file.
 Overkill but should also work, *something like*: 
  cd scripts/python  
  edit ../pkginfo.txt 
  remove these two lines: 
    odbc database 
    postgres95 database  
  rm ../PKGS # might not be needed but doesn't hurt  
  ./upgrade.py   # be current in whatever you are using i.e. LINUXLIBC6 
  ./do-cm3-all.py realclean I386_LINUX 
  ./do-cm3-all.py buildship I386_LINUX 
     # Quick test of compiler, should run and error: 
     ../../m3-sys/cm3/I386_LINUX/cm3 
    If it fails though, we have already shipped most stuff, so not good. 
    I need to rewrite these steps to be more friendly if they fail. 
  # and then some final small steps 
   ./install-cm3-compiler.py I386_LINUX 
   ./make-dist-cfg.py I386_LINUX  # does very little, you could instead edit your config 


 I have to run through this still myself. 
 With the last two steps, it should use I386_LINUX by default you don't have to keep saying it.  

 This is less overkill if e.g. you want to switch from LINUXLIBC6 to AMD64_LINUX.

 To use the C compiler, similarly: 
  cd scripts/python 
  edit ../pkginfo.txt 
  remove these two lines: 
    odbc database  
    postgres95 database  
  rm ../PKGS # might not be needed but doesn't hurt  
  ./upgrade.py   # be current in whatever you are using -- no need to a second time if did previous  
  ./do-cm3-all.py realclean I386_LINUX c   # notice the c throw in there  
  ./do-cm3-all.py buildship I386_LINUX c   # notice the c throw in there  
     # Quick test of compiler, should run and error: 
     ../../m3-sys/cm3/I386_LINUX/cm3 
    If it fails though, we have already shipped most stuff, so not good. 
    I need to rewrite these steps to be more friendly if they fail. 

  # and then some final small steps 
  ./install-cm3-compiler.py I386_LINUX c 
  ./make-dist-cfg.py I386_LINUX   
 Now, the last step, if you aren't going to be using the scripts all the time...you have to edit your bin/config/cm3cfg.common to enable the C backend. 
 Where it says:
 if not defined ("M3_BACKEND_MODE") 
     M3_BACKEND_MODE = "3" 
     % -- defines how the frontend, backend, and assembler interact 
     %  "0"  -- don't call m3_backend, M3CG produces object code 
     %  "1"  -- don't call m3_backend, M3CG produces assembly code 
     %  "2"  -- call m3_backend, it produces object code 
     %  "3"  -- call m3_backend, it produces assembly code 
     %  "C"  -- use C backend, and then compile with compile_c() 
 end 
  
 change: 
     M3_BACKEND_MODE = "3"  
 to: 
     M3_BACKEND_MODE = "C"  
  I haven't tried these *exact* steps though. 

 We should nail the exact minimal steps and check them in to doc or scripts/python. 
 I'm sure these are not minimal -- we should split it up as minimal to get a compiler,
 and then separate to build the rest of the system. And we might want to try rename or copy instead
 of rebuild. 

Something not in-place will also be good, more like make-dist.py.
Sorry, I wanted to send more confident directions earlier but got hung up on some stuff. 


 - Jay



> Date: Sat, 4 Jun 2016 09:32:10 -0400
> From: hendrik at topoi.pooq.com
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] replace build system??
> 
> On Sat, Jun 04, 2016 at 01:08:23AM +0000, Jay K wrote:
> > Aside: 
> >  > LINIXLIBC 
> > Any chance people will move from: LINUXLIBC6  NT386   FreeBSD4   
> > SOLgnu   SOLsun   to:  I386_LINUX   I386_NT  I386_FREEBSD   
> > SPARC32_SOLARIS (which internally lets you chose C compiler) 
> > ?
> 
> How do I switch?  My compiler just uses LINIXLIBC6 whatever I do.  Is 
> there a way of telling it otherwise?  Do I have to reinstall from 
> scratch?  Is there an installer that knows I386_LINUX?  Last time I 
> looked there didn't seem to be.
> 
> >  They have all been present and working for years. 
> >  These other names are a warty legacy. 
> >  The name LINUXLIBC6 has 20+ years of outdated legacy encoded in it.   1) The assumption that Linux is x86 only.   2) The fact that libc5 back in kernel 1.x days, pre-pthreads or at least pre-NPTL, was incompatible with libc6.  There is more motivation imho for pthreads vs. userthreads targets, and C vs. gcc-based vs. LLVM-based targets. (LLVM-based should be link compatible with one of them though?) 
> 
> And how do I ask for the C code generator?
> 
> -- hendrik
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20160606/ca086123/attachment-0002.html>