<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'>Reasonable but painful. And varied.<div><br></div><div><br></div><div>Do you want the Apple-supplied tools or fetch various cc/ld source and build them?</div><div><br></div><div><br></div><div>For Windows, Microsoft or Cygwin or Mingw?<br><div><br></div><div>Probe the machine to see if the tools are already present?</div><div>Run cc/gcc/cl, see if it works?</div><div><br></div><div><br></div><div>I like the autoconf model here -- which is indeed that last point.</div><div>It tries to compile "int main() { return 0; }", if that works, great a working C compiler.</div><div>If it doesn't, it might fish around for a few, but ultimately it gives up, and the</div><div>user can set CC and CFLAGS. Or PATH to put what it knows about in $PATH.</div><div><br></div><div><br></div><div>It doesn't know how to apt-get install build-essentials or other.</div><div><br></div><div><br></div><div>I must say -- autoconf -- I don't like sh or m4, and it is slow, but it does kinda work well.</div><div>I wrestle with this. I output C and I need int8/int16/int32/int64.</div><div>I have the following choices</div><div> 1 assume char/short/int/__int64/long long </div><div> 2 #if on compiler for __int64 vs. long long</div><div> 3 try to check limits.h -- paying for the cost of #include for every compile </div><div> 4 check for STDC_VERSION and use inttypes.h/stdint.h</div><div> 5 autoconf</div><div> 6 something like autoconf </div><div><br></div><div><br></div><div>For now I do some mix of 1/2/3, but I have this nagging feeling that autoconf would</div><div>gain portability to more systems.</div><div><br></div><div><br></div><div>Modula-3 follows "the Perl way" and is ported everywhere.</div><div>Whereas autoconf can kind of cons up a port if the system is the combination</div><div>of already known elements. Only individual elements need to be known about,</div><div>not combinations.</div><div><br></div><div><br></div><div>autoconf again is ugly and slow, but it is better in terms of "cartesian factoring".</div><div><br></div><div>And it doesn't handle Microsoft tools well or at all.</div><div><br></div><div><br></div><div>Also I have a similar nagging dilemma on bootstrap archives.</div><div>I want some incrementally. So I want e.g. make.</div><div>I want (currently lack) some hierarchy. So I want recursive make or maybe GNU make-specific.</div><div>Maybe automake? Which still doesn't buy me MS make.</div><div>cmake?</div><div>I don't really want to reinvent portability beyond GNU make.</div><div>out-of-source builds? With bootstrapping? Overkill?</div><div>So I wonder if I should, gasp, generate automake input.</div><div><br></div><div>make does though cater to the new generation and their IDEs, while also catering to the old ways.</div><div>KDE's use of it is a big gote</div><div><br></div><div><br></div><div> - Jay</div><div><br><br><br><div><hr id="stopSpelling">Date: Fri, 14 Aug 2015 12:32:02 -0700<br>From: lists@darko.org<br>To: jay.krell@cornell.edu<br>CC: m3devel@elegosoft.com<br>Subject: Re: [M3devel] Build Server - Plan<br><br><div dir="ltr">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.</div><div class="ecxgmail_extra"><br><div class="ecxgmail_quote">On Fri, Aug 14, 2015 at 12:11 PM, Jay K <span dir="ltr"><<a href="mailto:jay.krell@cornell.edu" target="_blank">jay.krell@cornell.edu</a>></span> wrote:<br><blockquote class="ecxgmail_quote" style="border-left:1px #ccc solid;padding-left:1ex;">
<div><div dir="ltr">For SPARC we have the opencsw machines.<div><br></div><div>make-dist.py builds .deb files already automatically.</div><div>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".</div><div><br></div><div>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.</div><div><br></div><div><br></div><div>make-diet.py builds .msi files for Windows already.</div><div>I generate a bunch of .xml and then run the wix tools.</div><div><br></div><div><br></div><div>We don't have any Mac installers.</div><div>You just extract a .tar.gz of binaries and set PATH.</div><div>That works on all platforms.</div><div><br></div><div>I also recently wrote the very short and simple capture-min.py</div><div>that captures a minimal cm3/m3core/libm3 from your existing install (you have to edit the path).</div><div>For native building.</div><div><br></div><div>Really this stuff isn't so difficult, but I don't explain it well, and I didn't invest much in "package building".</div><div><br></div><div> - Jay<br><br><br><br><div><hr>Date: Fri, 14 Aug 2015 09:22:08 -0700<span><br>From: <a href="mailto:lists@darko.org" target="_blank">lists@darko.org</a><br>To: <a href="mailto:m3devel@elegosoft.com" target="_blank">m3devel@elegosoft.com</a><br>Subject: Re: [M3devel] Build Server - Plan<br><br></span><div><div class="h5"><div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>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>"</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div><br><div>On Thu, Aug 13, 2015 at 11:36 PM, <span dir="ltr"><<a href="mailto:microcode@zoho.com" target="_blank">microcode@zoho.com</a>></span> wrote:<br><blockquote style="border-left:1px #ccc solid;padding-left:1ex;"><span>On Thu, Aug 13, 2015 at 01:27:54PM -0700, Darko Volaric wrote:<br>
</span><span>> I'm setting up a server for building CM3 that takes a "minimalist" approach.<br>
><br>
> It's a machine running several virtual machines, one for each platform<br>
> supported by CM3. Each VM will contain clean install of the OS plus any<br>
> external tool dependencies. It will have a minimal compiler install,<br>
> basically enough to compile itself for the host target.<br>
<br>
</span>Doesn't CM3 support Solaris SPARC? As far as I know there is no cheap way to<br>
emulate this from Intel.<br>
<span><br>
> The publicly available build products will be:<br>
><br>
> - minimal executables for bootstrap, eg the frontend and a backend<br>
> - model compiler config files<br>
> - compilation logs for bootstrap executables<br>
> - compilation logs for most modules in the github repository<br>
> - logs for certain tests<br>
<br>
</span>This sounds like a setup for experts. Why not make a turn-key tarball<br>
available like was available (I think) before?<br>
<span><br>
> Packages, libraries, scripts and non-essential tools or executables will<br>
> not be built or used, the idea being that people take the minimal<br>
> bootstraps and build from there.<br>
<br>
</span>That's fine for the 3 or 4 core guys doing all the work! For everybody else<br>
this is a big inhibitor to making CM3 generally useful to the rest of the<br>
world- unless the instructions to get a complete install are very clear and<br>
easy to follow. But it seems from watching the discussion here it is<br>
non-trivial to get CM3 installed.<br>
<div><div><br>
<br>
_______________________________________________<br>
M3devel mailing list<br>
<a href="mailto:M3devel@elegosoft.com" target="_blank">M3devel@elegosoft.com</a><br>
<a href="https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel" rel="noreferrer" target="_blank">https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel</a><br>
</div></div></blockquote></div><br></div>
<br>_______________________________________________
M3devel mailing list
<a href="mailto:M3devel@elegosoft.com" target="_blank">M3devel@elegosoft.com</a>
<a href="https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel" target="_blank">https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel</a></div></div></div></div> </div></div>
</blockquote></div><br></div>
<br>_______________________________________________
M3devel mailing list
M3devel@elegosoft.com
https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel</div></div></div> </div></body>
</html>