[M3devel] Build Server - Plan

Fri Aug 14 22:22:10 CEST 2015

Good thinking...but not easy to pick the one.People will complain no matter what you chose.MS? Cygwin? Mingw? Cross inhibits MS.Cross that isn't prebuilt will take a while to build.MS probably not redistributable. Have to point people at a web page. Chasing annual versions..
 - Jay

Date: Fri, 14 Aug 2015 12:48:29 -0700
Subject: Re: [M3devel] Build Server - Plan
From: lists at darko.org
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com

No, the idea is to pick one strategy. People don't need a lot of choices, just one good one. I see the installer installing its own (static) tools (included in the installer) in its own place, or possibly relying on XCode.
This is for people who want something simple, fixed and turnkey. Others can set up their own.
On Fri, Aug 14, 2015 at 12:42 PM, Jay K <jay.krell at cornell.edu> wrote:

Reasonable but painful. And varied.

Do you want the Apple-supplied tools or fetch various cc/ld source and build them?

For Windows, Microsoft or Cygwin or Mingw?

Probe the machine to see if the tools are already present?Run cc/gcc/cl, see if it works?

I like the autoconf model here -- which is indeed that last point.It tries to compile "int main() { return 0; }", if that works, great a working C compiler.If it doesn't, it might fish around for a few, but ultimately it gives up, and theuser can set CC and CFLAGS. Or PATH to put what it knows about in $PATH.

It doesn't know how to apt-get install build-essentials or other.

I must say -- autoconf -- I don't like sh or m4, and it is slow, but it does kinda work well.I wrestle with this. I output C and I need int8/int16/int32/int64.I have the following choices 1 assume char/short/int/__int64/long long  2 #if on compiler for __int64 vs. long long 3 try to check limits.h -- paying for the cost of #include for every compile  4 check for STDC_VERSION and use inttypes.h/stdint.h 5 autoconf 6 something like autoconf 

For now I do some mix of 1/2/3, but I have this nagging feeling that autoconf wouldgain portability to more systems.

Modula-3 follows "the Perl way" and is ported everywhere.Whereas autoconf can kind of cons up a port if the system is the combinationof already known elements. Only individual elements need to be known about,not combinations.

autoconf again is ugly and slow, but it is better in terms of "cartesian factoring".
And it doesn't handle Microsoft tools well or at all.

Also I have a similar nagging dilemma on bootstrap archives.I want some incrementally. So I want e.g. make.I want (currently lack) some hierarchy. So I want recursive make or maybe GNU make-specific.Maybe automake? Which still doesn't buy me MS make.cmake?I don't really want to reinvent portability beyond GNU make.out-of-source builds? With bootstrapping? Overkill?So I wonder if I should, gasp, generate automake input.
make does though cater to the new generation and their IDEs, while also catering to the old ways.KDE's use of it is a big gote

 - Jay

Date: Fri, 14 Aug 2015 12:32:02 -0700
From: lists at darko.org
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] Build Server - Plan

I think the Mac and Win installers should also install the required external tools, so it all "just works", which makes it a bit more difficult. Either way not a priority right now.
On Fri, Aug 14, 2015 at 12:11 PM, Jay K <jay.krell at cornell.edu> wrote:

For SPARC we have the opencsw machines.
make-dist.py builds .deb files already automatically.Somewhat crude in terms of package granularity and declared depenencies and such. We have "min" and "all" and no declared dependencies, though you need a C toolset -- "build-essentials".
A .deb file is just .tar.gz or .tar.xz or .tar.bz2 or .tar.lzma with some extra text files, wrapped up in an ar file.

make-diet.py builds .msi files for Windows already.I generate a bunch of .xml and then run the wix tools.

We don't have any Mac installers.You just extract a .tar.gz of binaries and set PATH.That works on all platforms.
I also recently wrote the very short and simple capture-min.pythat captures a minimal cm3/m3core/libm3 from your existing install (you have to edit the path).For native building.
Really this stuff isn't so difficult, but I don't explain it well, and I didn't invest much in "package building".
 - Jay

Date: Fri, 14 Aug 2015 09:22:08 -0700
From: lists at darko.org
To: m3devel at elegosoft.com
Subject: Re: [M3devel] Build Server - Plan

The solution for SPARC might be to create a cross-compiler. That's not ideal but would be useful for verifying that things compile for the platform at least, short of having the right hardware.
I disagree with your "only for experts" assessment. The point of this server is that you don't have to compiler the compiler and a backend just to get the latest (or even a properly working) compiler. That's the very "expert" work I'm trying to automate.
What this system spits out is everything you need to compile anything you want - a complete and working compiler. Not everyone wants or needs to use all the packages. If you do, you can. Here are the instructions for doing that: "cd <source dir>; cm3 <options>"
At some later date I'll also be working on MacOS, Windows and Debian installers, and installation will be trivial then. Until then it will be a matter of following simple instructions to set up CM3 the required tools.
I'll be opening up the server to anyone who wants to do something different. If someone wants to produce tarballs they can setup their own VMs and they will get built too.

On Thu, Aug 13, 2015 at 11:36 PM,  <microcode at zoho.com> wrote:
On Thu, Aug 13, 2015 at 01:27:54PM -0700, Darko Volaric wrote:

> I'm setting up a server for building CM3 that takes a "minimalist" approach.

>

> It's a machine running several virtual machines, one for each platform

> supported by CM3. Each VM will contain clean install of the OS plus any

> external tool dependencies. It will have a minimal compiler install,

> basically enough to compile itself for the host target.

Doesn't CM3 support Solaris SPARC? As far as I know there is no cheap way to

emulate this from Intel.

> The publicly available build products will be:

>

> - minimal executables for bootstrap, eg the frontend and a backend

> - model compiler config files

> - compilation logs for bootstrap executables

> - compilation logs for most modules in the github repository

> - logs for certain tests

This sounds like a setup for experts. Why not make a turn-key tarball

available like was available (I think) before?

> Packages, libraries, scripts and non-essential tools or executables will

> not be built or used, the idea being that people take the minimal

> bootstraps and build from there.

That's fine for the 3 or 4 core guys doing all the work! For everybody else

this is a big inhibitor to making CM3 generally useful to the rest of the

world- unless the instructions to get a complete install are very clear and

easy to follow. But it seems from watching the discussion here it is

non-trivial to get CM3 installed.

_______________________________________________

M3devel mailing list

M3devel at elegosoft.com

https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel

_______________________________________________
M3devel mailing list
M3devel at elegosoft.com
https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel 		 	   		  

_______________________________________________
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/75d99b76/attachment-0002.html>