[M3devel] Build Server - Plan

[Jay K]

 >  people are in a consolidating mood it might be good to > just use the Solaris Studio version instead of gcc on that platform.
I already mostly solved this years ago.

SOLgnu and SOLsun were always already the same, e.g. same threading,same jmpbuf, except the config files picked a different C compiler and differentoutput directory name.

I decided it shouldn't be separate paths everywhere in cm3/config files,only which C compiler to run and output directory names.That is, only the config files should vary.

We have a somewhat separate notion of "TARGET" and "BUILD_DIR".We might need to better about that.For example profile build get "p" appended to BUILD_DIR, but still the same TARGET.We need BUILD_DIR=SOLgnu but TARGET=SPARC32_SOLARIS.
The "new" target names are SPARC32_SOLARIS, SPARC64_SOLARIS, and I386_SOLARIS,AMD64_SOLARIS. In the config files you can pick GNU or Sun compiler.I invented a separate variable with better granularity.
Just look at SPARC32_SOLARIS:
readonly TARGET = "SPARC32_SOLARIS"readonly C_COMPILER = "SUN" % or GNU (SOLgnu configuration)include("SPARC32_SOLARIS.common")
and then SPARC32_SOLARIS.common looks for the compiler you ask for,and makes the switches match also.
Rodney gave me the term for this elegance the other day -- "Cartesian factoring".

Or, only factor out what varies. Where things are the same, don't duplicate.

In the old days the config files were very monolithic and there was duplication all over the place.For example, in the old days, HPPA implies HP-UX, but now HPPA can be Linux, NetBSD, FreeBSD, etc.The HPPA part is one file, the Linux/NetBSD/FreeBSD parts are their own single files.We only have a combinatorial explosion of small config files, not large ones.Even this could be improved -- runtime composition?
The old days had somewhat less sharing. i.e. we probably used "vendor" cc/as/ld more and GNUless. But there is still good allowance for that now.
I similarly refactor I386_NT.It was called NT386.The "mingw" platform is largely the same -- Win32 threads, Win32 I/O, Win32 GUI, GNU compiler/assembler/linker.There I came up with several variables for the factoring:
See NT.commonTHREAD_LIBRARY = MS or PTHREADSWINDOW_LIBRARY = MS or XLINKER = MS or GNUC_COMPILER = MS or GNU (should add "clang" or "llvm" as an option here)

LINUXLIBC6 is now I386_LINUX.
NT386GNU is I386_CYGWIN or I386_MINGW
A problem I ran into though wrt SOLgnu/SOLsun/LINUXLIBC6/NT386 is that nobodyusing them wanted to switch the name.

So I fixed n systems by renaming to m, leaving us with n + m, but they are justlayered over very common stuff. It doesn't take n + m work to implement.But the system is cluttered.

Has anyone switched from LINUXLIBC6 to I386_LINUX? Can we delete LINUXLIBC6?Has anyone/everyone switched from SOLsun/SOLgnu to SPARC32_SOLARIS?FreeBSD4 to I386_FREEBSD?
Well, at least all the AMD64 and DARWIN targets are well named.The others maybe aren't used much either way..

 - Jay


> Date: Fri, 14 Aug 2015 14:49:56 +0000
> From: microcode at zoho.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] Build Server - Plan
> 
> Hi, please see comments within:
> 
> On Fri, Aug 14, 2015 at 07:02:51AM +0000, Jay K wrote:
> 
> > It is very easy to install.
> 
> Ok, from what I read here I misunderstood. But I am glad to hear it.
> 
> > Yes we support significantly more than x86/amd64.
> 
> Thanks for the explanation. I am following projects that run on non-Intel
> platforms and I get a little concerned when there is movement to only run on
> Intel or when there seems to be the position Intel is all there is. While I
> concede Intel is overwhelmingly what people have there is also some very
> nice and increasingly cheap really good hardware based on other, better
> architectures and it's a shame to see that ignored into obvlivion.
> 
> I was happy to see the broad range of hardware and OS when I looked at the
> CM3 download page so when somebody noted he was going to tackle the Big 3 I
> was concerned because many projects and OS are now pretty much Intel only
> which I think is both unfortunate and also technically limiting in terms of
> code quality.
> 
> > We have SPARC32_SOLARIS and SPARC64_SOLARIS, that I test on the opencsw
> > machines -- very recently even.In the 5.8.6 timeframe, I was setup to
> > build and test PPC_DARWIN, PPC_LINUX, SPARC32_LINUX.Look at
> > m3-sys/m3cc/src/buildmany.sh. All but ARM_DARWIN there i just built
> > tonight -- the gcc-based backend. 
> 
> I remember we talked about the confusion of the various flavors of SPARC
> listed in the downloads section. If people are in a consolidating mood it
> might be good to just use the Solaris Studio version instead of gcc on that
> platform.
> 
> > Our portability rests on gcc, or now a C compiler, or now maybe LLVM,
> 
> Well, LLVM is a significant inhibitor to running anywhere but Intel as far
> as I know. LLVM SPARC does not seem to even be in the alpha stage and
> doesn't look like it's on anybody's list of things to do. LLVM MIPS is also
> not working well from the looks of things on the Debian MIPS list. Other
> projects that have adopted LLVM seem to use it only on Intel and have stayed
> with gcc on other platforms. There is a concern that will eventually be too
> difficult to maintain and the natural solution will be to abandon non-Intel
> hardware.
> 
> I understand and agree with the value of LLVM from the standpoint of
> reducing code complexity over gcc and also the more liberal license but it's
> disappointing to see only the Intel support is probably ever going to be
> worth anything as far as LLVM goes.
> 
> > The system was already very portable. I have made it easier to port.
> > 
> > I assume the "difficult" goals are meant to be ensure that people don't
> > have to jump through the hoops of "install lots of extra stuff" to get it
> > to work. 
> 
> I really don't know but I would agree with that. The install should go in
> standard paths and not require any prereqs, if possible.
> 
> Thank you.
> 
> 
> _______________________________________________
> 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/20150814/67ec9349/attachment-0002.html>