<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'><div> I'm pretty convinced the thing to do here, is still run cm3 in its "bulk" </div><div> way, to output a bunch of .mc/.ic or .c files, and then use autotools/libtool, </div><div> or possibly cmake to run the C compiler, the assembler, and lib/linker, and probably </div><div> for ship/install as well. </div><div><br></div><div><br></div><div> It should output configure.ac/Makefile.am files. </div><div><br></div><div><br></div><div> This would give us both much increased portability and much decreased maintenance. </div><div> And we'd use make -j for parallelism. </div><div> The config files would go away. Quake might even go away. </div><div><br></div><div><br></div><div> I oscillate between, on one side:</div><div> There exists Posix cc, so one can portably run a C compiler.</div><div> And ar+ranlib are very well standardized.</div><div> But we go well beyond that -- we run the assembler, we produce shared libraries. </div><div><br></div><div><br></div><div> We support many systems, with fairly minimal and efficient layering, but</div><div> autotools/libtool and cmake go much further out of their way and support more. We</div><div> basically only have gcc-based, gcc-like, and Solaris.</div><div> gcc-like, I mean, Apple's clang accepts gcc options.</div><div><span style="font-size: 12pt;"> </span></div><div><br></div><div> When using the C backend, we could do another trick -- generate 4+ variations </div><div> all in one file each with #if's around them: </div><div><br></div><div><br></div><div> #if 32bit and little endian and posix // x86, arm32 </div><div> ... </div><div> #elif 64bit and little endian and posix // amd64, arm64 </div><div> ... </div><div> #elif 32bit and big endian and posix // sparc32, ppc_darwin </div><div> ... </div><div> #elif 64bit and big endian and posix // sparc64, ppc64_darwin </div><div> ... </div><div> #endif </div><div><br></div><div> The #if's would be controlled by autoconf. </div><div><br></div><div><br></div><div> We'd have one slightly bloated source distribution for all Posix systems. </div><div><br></div><div><br></div><div> I know the autotools have a very mixed reputation, and it is deserved.</div><div> Instead of sh/m4/sed/awk/make/python, they should just us C/C++, maybe Python.</div><div> Their portability is difficult to reject though.</div><div> </div><div><br></div><div> - Jay</div><br><br><br><div><hr id="stopSpelling">From: jay.krell@cornell.edu<br>To: hendrik@topoi.pooq.com<br>Date: Mon, 6 Jun 2016 17:39:49 +0000<br>CC: m3devel@elegosoft.com<br>Subject: Re: [M3devel] replace build system??<br><br>
<style><!--
.ExternalClass .ecxhmmessage P {
padding:0px;
}
.ExternalClass body.ecxhmmessage {
font-size:12pt;
font-family:Calibri;
}
--></style>
<div dir="ltr"><div>Fair questions.</div><div><br></div><div><br>LINUXLIBC6 and I386_LINUX are the same really.</div><div><br></div><div>It should work to just rename a few files and change the string in the config file.</div><div><br></div><div> Overkill but should also work, *something like*: </div><div><br></div><div> cd scripts/python <br> edit ../pkginfo.txt <br> remove these two lines: <br> odbc database <br> postgres95 database <br> rm ../PKGS # might not be needed but doesn't hurt <br> ./upgrade.py # be current in whatever you are using i.e. LINUXLIBC6 <br> ./do-cm3-all.py realclean I386_LINUX <br> ./do-cm3-all.py buildship I386_LINUX <br> # Quick test of compiler, should run and error: <br> ../../m3-sys/cm3/I386_LINUX/cm3 <br> If it fails though, we have already shipped most stuff, so not good. <br> I need to rewrite these steps to be more friendly if they fail. </div><div><br></div><div> # and then some final small steps <br> ./install-cm3-compiler.py I386_LINUX <br> ./make-dist-cfg.py I386_LINUX # does very little, you could instead edit your config </div><div><br></div><div><br></div><div><br></div><div> I have to run through this still myself. <br> With the last two steps, it should use I386_LINUX by default you don't have to keep saying it. </div><div><br></div><div><br></div><div> This is less overkill if e.g. you want to switch from LINUXLIBC6 to AMD64_LINUX.</div><div><br></div><div><br> To use the C compiler, similarly: <br> cd scripts/python <br> edit ../pkginfo.txt <br> remove these two lines: <br> odbc database <br> postgres95 database <br> rm ../PKGS # might not be needed but doesn't hurt <br> ./upgrade.py # be current in whatever you are using -- no need to a second time if did previous <br> ./do-cm3-all.py realclean I386_LINUX c # notice the c throw in there <br> ./do-cm3-all.py buildship I386_LINUX c # notice the c throw in there <br> # Quick test of compiler, should run and error: <br> ../../m3-sys/cm3/I386_LINUX/cm3 <br> If it fails though, we have already shipped most stuff, so not good. <br> I need to rewrite these steps to be more friendly if they fail. <br></div><div><br></div><div> # and then some final small steps <br> ./install-cm3-compiler.py I386_LINUX c <br> ./make-dist-cfg.py I386_LINUX </div><div><br></div><div> 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. <br> Where it says:</div><div><br></div><div> if not defined ("M3_BACKEND_MODE") <br> M3_BACKEND_MODE = "3" <br> % -- defines how the frontend, backend, and assembler interact <br> % "0" -- don't call m3_backend, M3CG produces object code <br> % "1" -- don't call m3_backend, M3CG produces assembly code <br> % "2" -- call m3_backend, it produces object code <br> % "3" -- call m3_backend, it produces assembly code <br> % "C" -- use C backend, and then compile with compile_c() <br> end <br> </div><div><br></div><div> change: <br> M3_BACKEND_MODE = "3" </div><div><br></div><div> to: <br> M3_BACKEND_MODE = "C" </div><div><br></div><div> I haven't tried these *exact* steps though. </div><div><br></div><div><br> We should nail the exact minimal steps and check them in to doc or scripts/python. <br> I'm sure these are not minimal -- we should split it up as minimal to get a compiler,<br> and then separate to build the rest of the system. And we might want to try rename or copy instead<br> of rebuild. </div><div><br></div><div><br>Something not in-place will also be good, more like make-dist.py.<br>Sorry, I wanted to send more confident directions earlier but got hung up on some stuff. </div><div><br></div><div><br></div><div><br></div><div> - Jay<br><br><br><br></div><div>> Date: Sat, 4 Jun 2016 09:32:10 -0400<br>> From: hendrik@topoi.pooq.com<br>> To: jay.krell@cornell.edu<br>> CC: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] replace build system??<br>> <br>> On Sat, Jun 04, 2016 at 01:08:23AM +0000, Jay K wrote:<br>> > Aside: <br>> > > LINIXLIBC <br>> > Any chance people will move from: LINUXLIBC6 NT386 FreeBSD4 <br>> > SOLgnu SOLsun to: I386_LINUX I386_NT I386_FREEBSD <br>> > SPARC32_SOLARIS (which internally lets you chose C compiler) <br>> > ?<br>> <br>> How do I switch? My compiler just uses LINIXLIBC6 whatever I do. Is <br>> there a way of telling it otherwise? Do I have to reinstall from <br>> scratch? Is there an installer that knows I386_LINUX? Last time I <br>> looked there didn't seem to be.<br>> <br>> > They have all been present and working for years. <br>> > These other names are a warty legacy. <br>> > 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?) <br>> <br>> And how do I ask for the C code generator?<br>> <br>> -- hendrik<br></div> </div>
<br>_______________________________________________
M3devel mailing list
M3devel@elegosoft.com
https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel</div> </div></body>
</html>