[M3devel] replace build system??

Jay K jay.krell at cornell.edu
Sun Jun 26 09:15:37 CEST 2016


>> 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 


Ok I went through this exercise.


Finally getting at least some cross tools on the Linux/amd64 system to target x86.
gcc and libc but not libxaw.


I had some trial/error and hits/misses.
I started from no x86 tools (not even gcc)
and I never got 32bit Xaw working on AMD64 Linux working.
So I did remove all the gui stuff from pkginfo.txt.
But a native system won't have these troubles.


But anyway, based on my experience:


 vi $HOME/cm3.l6/bin/cm3.cfg 


 Change HOST and TARGET to I386_LINUX unconditionally: 
 
 
 jay at debamd64:~/dev2/cm3/m3-libs/m3core$ cat  /home/jay/cm3.l6/bin/cm3.cfg  
 if not defined("SL") SL = "/" end 
 HOST = "I386_LINUX" 
 TARGET = "I386_LINUX" 
 INSTALL_ROOT = (path() & SL & "..") 
 include(path() & SL & "config" & SL & TARGET) 
 
 
 You have to change them both for the existing cm3cg to be used. 
 There are ways other than changing HOST, lik3 cm3 -Dm3back=cm3cg. 


 Your tree probably needs to be all in sync first for this to work, due to the reuse of existing cm3 and cm3cg with a fresh m3core/libm3.
 i.e. first do an upgrade.py. 


  Manually build m3core/libm3.  
   
  cd $ROOT/m3-libs/m3core  
  cm3  
  cm3 -ship   
  cd ../libm3  
  cm3  
  cm3 -ship  
 
   
   and then scripts/python/upgrade-full.sh  

That's it. Pretty easy.

If you want to skip the upgrade, you can probably first copy the LINUXLIBC6 pkg/m3core, libm3 to I386_LINUX.

 - 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 
 		 	   		  


More information about the M3devel mailing list