[M3devel] Build Server - Plan

Tue Aug 18 01:42:03 CEST 2015

I think you want is roughly:
  boot1.py over each architecture 
  package those up 
  along with matching m3core/libm3/m3cc source
  boot2.sh or such on the target system -- but this currently
   assumes an entire matching source tree, so this needs work 

But fair enough, you just want compilers, to get around the "crossing".
Crossing is easy as far as we do it -- just see boot1.py.
It only gets as far as assembly files. Then you move them to the target
machine and run native assembler and linker.

ARM_LINUX is a sore point for me.
Debian has been through at least three different arm ports.
For this all to work reasonably cleanly we have to track
something like this:
 https://wiki.debian.org/Multiarch/Tuples 

Meanwhile, m3front barely cares about platform at all.
Almost all platforms generate identical code until they hit the backend.
And even then they are identical, e.g. I386_LINUX, I386_FREEBSD, I386_OPENBSD,
I386_NETBSD, I386_SOLARIS likely as identical -- the ABI and the object file format.

Our "porting" and "supported platforms" is much ado about little.
We support "everything and nothing", by leveraging underlying gcc
or C compiler and pthreads or Win32, and X or Win32.

 - Jay

Date: Sun, 16 Aug 2015 20:14:27 -0700
Subject: Re: [M3devel] Build Server - Plan
From: lists at darko.org
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com; microcode at zoho.com

If you want the "entire system" then go ahead and build it. But you can't do that without "just the compiler" (a bootstrap compiler). That's what I'm trying to provide for every supported platform: the bare essentials.
If you say  "that's not very useful," then I'd say that having no compiler at all is much less useful, since you can't have any system, complete or not, unless you go through the oneous task of building a cross compiler.
For example, we have a working ARM_LINUX platform, but no publically available bootstrap compiler. What's the point of that? How is being able to compile X programs on Darwin going to fix that? Asking potential users to first get a system that does have a compiler then build a cross compiler is not realistic.
(You can compile the m3core and libm3 libraries from source having just the bootstrap compiler. If you can't compile m3core/m3lib without an existing m3core/m3lib then I'd call that a bug. Surely the dependency is having the right version of the source, not having a compiled library included with your compiler.)

On Sun, Aug 16, 2015 at 6:24 PM, Jay <jay.krell at cornell.edu> wrote:
I meant like "the entire system" not "just the compiler". Right, to link it all.

The compiler has to come with a matching m3core/libm3, binary and/or source. The cm3cg binary can be built from source, but again it has to be matching -- or use C backend.

Python is convenient for cross-platform scripting, but optional.
 - Jay
On Aug 16, 2015, at 5:04 PM, Darko Volaric <lists at darko.org> wrote:

Minimal is cm3 + cm3cg + config file. I'm pretty sure everything else can be built from that, but someone might correct me.
The required tools issue is solved by only supporting one standard, minimal toolset (mostly just gcc), installed in a particular place. I'm not trying to support or test every configuration, just one. It's for people who are starting from scratch and also serves as a baseline for testing.
I don't understand what your "dependency on X" issue is. As far as I know there are no external source dependencies in the frontend and the backend depends only on the gcc source which is in the repository. The build server only builds the frontend and backend executables, nothing else, so there are no other dependencies.
If you're talking about building an X Windows application, I still don't get it. Why do I need to support someone wanting to write an X program? I'm not supporting people who want to do anything other than run the compiler on their platform. If they want to make X programs they can download and configure whatever is needed themselves. The CM3 compiler can compile (but not link) M3 interfaces and modules for X without having X installed. That's all I'm trying to support.

On Sun, Aug 16, 2015 at 2:40 PM, Jay K <jay.krell at cornell.edu> wrote:

What is minimal? sh? gcc? make? python? perl? A large .tar.gz file? X?

What is minimal for a user of cm3 vs. a developer of cm3?

I bring up X because there are many programs/demos in the distribution, including gui ones.
On many systems, even X is just an "apt get whatever" away.
And, if we form our .deb correctly, it is fairly automatic.
On MacOSX current what happens is if you an X program, you automatically get a popup prompting you to install.
On MacOSX current what happens if you try to build an X program, and don't have X installed, it fails. We can make it do nothing. We can link to the stub -- but then you have to relink after installing X.

How to ease that apart? A sort of dependency on X?
Likely separate packages, like cm3 and cm3-gui?

I keep thinking, for a developer but not user of cm3, the bootstrap archives should produce autoconf/automake inputs.
This handles, for example, "how do I invoke the C compiler?" -- even if using the gcc backend, we need a C compiler/linker/assembler.
Imagine if, you know, our config files dropped away entirely.
Imagine if the config file was generated at install time by autoconf.
Imagine if we didn't have a small amount of litter in our system as to how to link on HP-UX. Or if AIX supported was "inherited" from libtool.
Basically, libtool supports more than us an overlaps with us. Maybe reuse it.

Again, I am somewhat positively and negatively obsessed with "the GNU build system"
It is slow and bad to author in, but produces easy to use somewhat slow idiomatic results.

Also, to reiterate, I believe the point here was the "build server" would be complicated, in order to produce easy to use outputs.

One also needs to keep in mind the somewhat opposing but common desires: install from source vs. install from binaries.
Install from binaries is faster.
Install from source is problematic for compilers written in themselves. Even gcc.

 - Jay

Date: Sun, 16 Aug 2015 13:59:15 -0700
From: lists at darko.org
To: m3devel at elegosoft.com; microcode at zoho.com
Subject: Re: [M3devel] Build Server - Plan

Just like there are different views on how Linux should be set up and thus different distributions, there are different views on how CM3 should be setup or installed, or at least I have a different view.
I definitely believe in the "effortlessly and mindlessly" thing, and I want to take it further than the current installer. In particular I want to reduce the external, internal and environmental dependencies so that you can build anything, anywhere with just the minimal set of executables and a standard set of tools. Others want a more elaborate setup which gives them more flexibility; that can also be derived from that same minimal set.

On Sun, Aug 16, 2015 at 12:27 AM,  <microcode at zoho.com> wrote:
On Fri, Aug 14, 2015 at 09:22:08AM -0700, Darko Volaric wrote:

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

You should have access to opencsw as Jay mentioned. If not, I can offer

machine time but I can't keep the machine running all the time. Hopefully

the current setup (opencsw) is still viable.

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

That is good to hear because from your list of deliverables it seemed to me

there would still be a lot of tinkering to get a complete install. If you

are scripting that and it can be built effortlessly and mindlessly from the

deliverables then good. I think it would be ideal and very nice if people

could download a turnkey tarball ready to run on their platform, or source

code ready to build and an installer script that installs the final

product. Jay mentioned autotools and they are usually far from optimal on

Solaris because of autotools reliance on so much gnu stuff that is not

always necessarily present on Solaris but that is the general idea- to be

able to configure && make && make install with all the standard stuff

happening like everything being installed in /usr/local/bin|lib|share and so

forth.

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

It was probably just my unfamiliarity with the build setup and terms. I'm

sorry if I wasted anybody's time with this diversion. I have been following

the mailing list and it looks like Jay and Rodney are mostly discussing

things with a very small number of regulars. Coming from the outside as I do

I think anybody new is going to have similar questions/misunderstandings of

how cm3 is built and installed, etc.

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

Hopefully this can be integrated with what you already have running on

opencsw.

Thank you.

_______________________________________________

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/20150817/b52d2f2f/attachment-0002.html>