<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'><pre style="line-height: 21.299999237060547px; white-space: normal; font-family: 'Segoe UI', 'Segoe UI Web Regular', 'Segoe UI Symbol', 'Helvetica Neue', 'BBAlpha Sans', 'S60 Sans', Arial, sans-serif; color: rgb(68, 68, 68); font-size: 15px;"> > people are in a consolidating mood it might be good to</pre><pre style="line-height: 21.299999237060547px; white-space: normal; font-family: 'Segoe UI', 'Segoe UI Web Regular', 'Segoe UI Symbol', 'Helvetica Neue', 'BBAlpha Sans', 'S60 Sans', Arial, sans-serif; color: rgb(68, 68, 68); font-size: 15px;"> > just use the Solaris Studio version instead of gcc on that platform.</pre><div><br></div>I already mostly solved this years ago.<div><br></div><div><br></div><div>SOLgnu and SOLsun were always already the same, e.g. same threading,</div><div>same jmpbuf, except the config files picked a different C compiler and different</div><div>output directory name.</div><div><br></div><div><br></div><div>I decided it shouldn't be separate paths everywhere in cm3/config files,</div><div>only which C compiler to run and output directory names.</div><div>That is, only the config files should vary.</div><div><br></div><div><br></div><div>We have a somewhat separate notion of "TARGET" and "BUILD_DIR".</div><div>We might need to better about that.</div><div>For example profile build get "p" appended to BUILD_DIR, but still the same TARGET.</div><div>We need BUILD_DIR=SOLgnu but TARGET=SPARC32_SOLARIS.</div><div><br></div><div>The "new" target names are SPARC32_SOLARIS, SPARC64_SOLARIS, and I386_SOLARIS,</div><div>AMD64_SOLARIS. In the config files you can pick GNU or Sun compiler.</div><div><font size="3">I invented a separate </font>variable<font size="3"> with better granularity.</font></div><div><font size="3"><br></font></div><div><font size="3">Just look at SPARC32_SOLARIS:</font></div><div><font size="3"><br></font></div><div><div><span style="font-size: 12pt;">readonly TARGET = "SPARC32_SOLARIS"</span></div><div>readonly C_COMPILER = "SUN" % or GNU (SOLgnu configuration)</div><div>include("SPARC32_SOLARIS.common")</div></div><div><br></div><div>and then SPARC32_SOLARIS.common looks for the compiler you ask for,</div><div>and makes the switches match also.</div><div><br></div><div>Rodney gave me the term for this elegance the other day -- "Cartesian factoring".</div><div><br></div><div><br></div><div>Or, only factor out what varies. Where things are the same, don't duplicate.</div><div><br></div><div><br></div><div>In the old days the config files were very monolithic and there was duplication all over the place.</div><div>For example, in the old days, HPPA implies HP-UX, but now HPPA can be Linux, NetBSD, FreeBSD, etc.</div><div>The HPPA part is one file, the Linux/NetBSD/FreeBSD parts are their own single files.</div><div>We only have a combinatorial explosion of small config files, not large ones.</div><div>Even this could be improved -- runtime composition?</div><div><br></div><div>The old days had somewhat less sharing. i.e. we probably used "vendor" cc/as/ld more and GNU</div><div>less. But there is still good allowance for that now.</div><div><br></div><div>I similarly refactor I386_NT.</div><div>It was called NT386.</div><div>The "mingw" platform is largely the same -- Win32 threads, Win32 I/O, Win32 GUI, GNU compiler/assembler/linker.</div><div>There I came up with several variables for the factoring:</div><div><br></div><div>See NT.common</div><div>THREAD_LIBRARY = MS or PTHREADS</div><div>WINDOW_LIBRARY = MS or X</div><div>LINKER = MS or GNU</div><div>C_COMPILER = MS or GNU (should add "clang" or "llvm" as an option here)</div><div><br></div><div><br></div><div>LINUXLIBC6 is now I386_LINUX.</div><div><br></div><div>NT386GNU is I386_CYGWIN or I386_MINGW</div><div><br></div><div><span style="font-size: 12pt;">A problem I ran into though wrt SOLgnu/SOLsun/LINUXLIBC6/NT386 is that nobody</span></div><div>using them wanted to switch the name.</div><div><br></div><div><br></div><div>So I fixed n systems by renaming to m, leaving us with n + m, but they are just</div><div>layered over very common stuff. It doesn't take n + m work to implement.</div><div>But the system is cluttered.</div><div><br></div><div><br></div><div>Has anyone switched from LINUXLIBC6 to I386_LINUX? Can we delete LINUXLIBC6?</div><div>Has anyone/everyone switched from SOLsun/SOLgnu to SPARC32_SOLARIS?</div><div>FreeBSD4 to I386_FREEBSD?</div><div><br></div><div>Well, at least all the AMD64 and DARWIN targets are well named.</div><div>The others maybe aren't used much either way..</div><div><br></div><div><br></div><div> - Jay<br><br><br><div>> Date: Fri, 14 Aug 2015 14:49:56 +0000<br>> From: microcode@zoho.com<br>> To: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] Build Server - Plan<br>> <br>> Hi, please see comments within:<br>> <br>> On Fri, Aug 14, 2015 at 07:02:51AM +0000, Jay K wrote:<br>> <br>> > It is very easy to install.<br>> <br>> Ok, from what I read here I misunderstood. But I am glad to hear it.<br>> <br>> > Yes we support significantly more than x86/amd64.<br>> <br>> Thanks for the explanation. I am following projects that run on non-Intel<br>> platforms and I get a little concerned when there is movement to only run on<br>> Intel or when there seems to be the position Intel is all there is. While I<br>> concede Intel is overwhelmingly what people have there is also some very<br>> nice and increasingly cheap really good hardware based on other, better<br>> architectures and it's a shame to see that ignored into obvlivion.<br>> <br>> I was happy to see the broad range of hardware and OS when I looked at the<br>> CM3 download page so when somebody noted he was going to tackle the Big 3 I<br>> was concerned because many projects and OS are now pretty much Intel only<br>> which I think is both unfortunate and also technically limiting in terms of<br>> code quality.<br>> <br>> > We have SPARC32_SOLARIS and SPARC64_SOLARIS, that I test on the opencsw<br>> > machines -- very recently even.In the 5.8.6 timeframe, I was setup to<br>> > build and test PPC_DARWIN, PPC_LINUX, SPARC32_LINUX.Look at<br>> > m3-sys/m3cc/src/buildmany.sh. All but ARM_DARWIN there i just built<br>> > tonight -- the gcc-based backend. <br>> <br>> I remember we talked about the confusion of the various flavors of SPARC<br>> listed in the downloads section. If people are in a consolidating mood it<br>> might be good to just use the Solaris Studio version instead of gcc on that<br>> platform.<br>> <br>> > Our portability rests on gcc, or now a C compiler, or now maybe LLVM,<br>> <br>> Well, LLVM is a significant inhibitor to running anywhere but Intel as far<br>> as I know. LLVM SPARC does not seem to even be in the alpha stage and<br>> doesn't look like it's on anybody's list of things to do. LLVM MIPS is also<br>> not working well from the looks of things on the Debian MIPS list. Other<br>> projects that have adopted LLVM seem to use it only on Intel and have stayed<br>> with gcc on other platforms. There is a concern that will eventually be too<br>> difficult to maintain and the natural solution will be to abandon non-Intel<br>> hardware.<br>> <br>> I understand and agree with the value of LLVM from the standpoint of<br>> reducing code complexity over gcc and also the more liberal license but it's<br>> disappointing to see only the Intel support is probably ever going to be<br>> worth anything as far as LLVM goes.<br>> <br>> > The system was already very portable. I have made it easier to port.<br>> > <br>> > I assume the "difficult" goals are meant to be ensure that people don't<br>> > have to jump through the hoops of "install lots of extra stuff" to get it<br>> > to work. <br>> <br>> I really don't know but I would agree with that. The install should go in<br>> standard paths and not require any prereqs, if possible.<br>> <br>> Thank you.<br>> <br>> <br>> _______________________________________________<br>> M3devel mailing list<br>> M3devel@elegosoft.com<br>> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel<br></div></div> </div></body>
</html>