[M3devel] Build Server - Plan

Fri Aug 14 21:48:29 CEST 2015

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 the
> user 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 would
> gain 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
> combination
> of 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.py
> that 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/dfb794b8/attachment-0002.html>