[M3devel] replace build system??

[Jay K]

 I'm pretty convinced the thing to do here, is still run cm3 in its "bulk"  way, to output a bunch of .mc/.ic or .c files, and then use autotools/libtool,  or possibly cmake to run the C compiler, the assembler, and lib/linker, and probably  for ship/install as well. 

 It should output configure.ac/Makefile.am files. 

 This would give us both much increased portability and much decreased maintenance.  And we'd use make -j for parallelism.    The config files would go away. Quake might even go away. 

 I oscillate between, on one side:   There exists Posix cc, so one can portably run a C compiler.   And ar+ranlib are very well standardized.   But we go well beyond that -- we run the assembler, we produce shared libraries. 

   We support many systems, with fairly minimal and efficient layering, but   autotools/libtool and cmake go much further out of their way and support more. We   basically only have gcc-based, gcc-like, and Solaris.   gcc-like, I mean, Apple's clang accepts gcc options.   
 When using the C backend, we could do another trick -- generate 4+ variations  all in one file each with #if's around them: 

  #if 32bit and little endian and posix  // x86, arm32    ...    #elif 64bit and little endian and posix  // amd64, arm64   ...    #elif 32bit and big endian and posix  // sparc32, ppc_darwin   ...      #elif 64bit and big endian and posix  // sparc64, ppc64_darwin   ...     #endif 
 The #if's would be controlled by autoconf. 

 We'd have one slightly bloated source distribution for all Posix systems. 

 I know the autotools have a very mixed reputation, and it is deserved.  Instead of sh/m4/sed/awk/make/python, they should just us C/C++, maybe Python.  Their portability is difficult to reject though.  
 - Jay


From: jay.krell at cornell.edu
To: hendrik at topoi.pooq.com
Date: Mon, 6 Jun 2016 17:39:49 +0000
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] replace build system??




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
 		 	   		  

_______________________________________________
M3devel mailing list
M3devel at elegosoft.com
https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20160619/a361bea2/attachment-0002.html>