<html><head></head><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px"><div>hi:</div><div>besides that cm3 v4 could compile pm3 anyway.<br></div><div><span></span></div> <div class="qtdSeparateBR"><br><br></div><div style="display: block;" class="yahoo_quoted"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div dir="ltr"><font face="Arial" size="2"> El Sábado 25 de junio de 2016 13:17, Daniel Alejandro Benavides D. <dabenavidesd@yahoo.es> escribió:<br></font></div> <br><br> <div class="y_msg_container"><div id="yiv3270809950"><div><div style="color:#000;background-color:#fff;font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px;"><div id="yiv3270809950yui_3_16_0_ym19_1_1466869564608_9658">Hi Jay, all:</div><div dir="ltr" id="yiv3270809950yui_3_16_0_ym19_1_1466869564608_9626">do you <span id="yiv3270809950yui_3_16_0_ym19_1_1466869564608_9625">remember that pm3 build run in make; do you remember the cross platform assembly generation model.</span></div><div dir="ltr" id="yiv3270809950yui_3_16_0_ym19_1_1466869564608_9623"><span id="yiv3270809950yui_3_16_0_ym19_1_1466869564608_9629">What do you think of it?<br clear="none"></span></div><div dir="ltr" id="yiv3270809950yui_3_16_0_ym19_1_1466869564608_9624"><span id="yiv3270809950yui_3_16_0_ym19_1_1466869564608_9628">Thanks in advance</span></div> <div class="yiv3270809950qtdSeparateBR"><br clear="none"><br clear="none"></div><div class="yiv3270809950yahoo_quoted" style="display:block;"> <div style="font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px;"> <div style="font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px;"> <div dir="ltr"><font face="Arial" size="2"> El Sábado 25 de junio de 2016 12:43, Jay K <jay.krell@cornell.edu> escribió:<br clear="none"></font></div> <br clear="none"><br clear="none"> <div class="yiv3270809950y_msg_container"><div class="yiv3270809950yqt3773075382" id="yiv3270809950yqt19385"><div id="yiv3270809950"><style>#yiv3270809950 --
.yiv3270809950hmmessage P
{
margin:0px;padding:0px;}
#yiv3270809950 body.yiv3270809950hmmessage
{
font-size:12pt;font-family:Calibri;}
#yiv3270809950 </style><div><div dir="ltr"><div>I agree and disagree.</div><div><br clear="none"></div><div><br clear="none"></div><div>Regarding Posix -- I think it did well for low level C.</div><div><br clear="none"></div><div><br clear="none"></div><div>I think we have some portability in Modula-3 as a result.</div><div>I agree they seemed to have done nothing for shared linking, for packaging,</div><div>and almost nothing for "make", and I guess X Windows didn't need their help,</div><div>at the time, people thought.</div><div><br clear="none"></div><div><br clear="none"></div><div>There is a clear resemblance among the build systems.</div><div>Even automake looks like cm3 from a user point of view.</div><div>Even the implementation:</div><div> automake "compiles" to make</div><div> cm3 "compiles" to quake</div><div><br clear="none"></div><div> </div><div>Quake was written in C.</div><div><br clear="none"></div><div><br clear="none"></div><div>The notion of a bunch of builtins and some escape hatch is also common.</div><div>Quake is a better escape hatch than cmake.</div><div><br clear="none"></div><div><br clear="none"></div><div>The notion of writing a build scripting language and/or a set of build functions</div><div>accessible to a scripting language is common -- in scons it is all just Python,</div><div>and they provide a library. The Unity?Unreal (I get these mixed up) build system</div><div>has all the "makefiles" written in C#, and actually adding a single source file</div><div>implies some automatic recompile, but it is a small/fast recompile, and</div><div>the resulting build system is fast, AND you can step through your build system</div><div>using an ordinary C# debugger -- trying doing that with cm3/quake/make!</div><div><br clear="none"></div><div><br clear="none"></div><div>cm3 kind of delegates to something kind of like autoconf, if you consider cminstall.</div><div>But the cminstall part I never liked -- it was interactive and we still have</div><div>to maintain the choices, and it was often wrong. It was too close to the "user edits it" model.</div><div><br clear="none"></div><div><br clear="none"></div><div>I'm aware of Docker.</div><div><br clear="none"></div><div><br clear="none"></div><div>I think it is solving a problem.</div><div> Not the entire problem -- cloud app declaration, software composition.</div><div> Though it still low level -- how do I describe and join multiple containers?</div><div><br clear="none"></div><div> </div><div>I'm not sure it is relevant here.</div><div><br clear="none"></div><div><br clear="none"></div><div>However, Docker-induced bloat alludes to static link bloat.</div><div>If we give up on dynamic linking, we get Posix-portable linking --</div><div>ar + ranlib + cc/ld are very portable. I'm reluctant to do that though.</div><div><br clear="none"></div><div><br clear="none"></div><div>I don't think C and autoconf/automake are clearly a step backward.</div><div><br clear="none"></div><div><br clear="none"></div><div>I want more portability and, I admit, less work.</div><div> I think they are great for portabilitity.</div><div> Even better, generate C++ and likely gain efficient exception handling.</div><div> Delegating the work to the C++ implementers, which generally</div><div> do much better than us here (basically inheriting "stack walkers"</div><div> wherever they exist.)</div><div><br clear="none"></div><div><br clear="none"></div><div>I want to be able to declare large swaths of the system ported/portable</div><div>and not have to constantly revisit them (or worry that they are neglected)</div><div><br clear="none"></div><div><br clear="none"></div><div>I don't want clang vs. gcc</div><div><span style="font-size:12pt;">to be something we have to worry about. I want want minor forks</span></div><div>like Dragonfly or the new OpenBSD fork to be something that requires</div><div>our attention to work, or perhaps even anyones -- if these systems resemble</div><div>Posix enough and/or use gcc, autoconf can just figure stuff out. Or maybe</div><div>we just have to pick up newer libtool sometimes.</div><div><br clear="none"></div><div><br clear="none"></div><div>If I write a substantial program in C or C++, and I use cmake or autoconf/libtool,</div><div>I can redistribute it easily as source and people can easily rebuild and install</div><div>and package it. I want our system to be similar.</div><div><br clear="none"></div><div><br clear="none"></div><div>There are middle grounds that don't "step backward".</div><div>We could:</div><div> - accept our current platforms/ports (i.e. don't fret over AIX, etc.) </div><div> - accept that the config files aren't bad asis </div><div> - bootstrap can just automate slightly more and build cm3 </div><div> - use cm3 to build and install everything else, including cm3cg,</div><div> dynamic linking, etc. </div><div> </div><div>That is, we can get close to configure && make && make install w/o much</div><div>change. Mostly like 3.6.</div><div><br clear="none"></div><div><br clear="none"></div><div>One nagging point is to distribute target specific cm3 bootstraps, or bundle</div><div>them all together and have something like "configure" pick which one.</div><div>You know -- does user have to pick among many downloads or just one.</div><div><br clear="none"></div><div>We can maintain the "configure && make && make install" model, but</div><div>they wouldn't use any of autoconf/automake.</div><div><br clear="none"></div><div>configure would determine what target to use</div><div>make would cd to that target and build cm3, statically linked</div><div>make would then use that cm3 to the entire system -- starting with cm3cg, and then m3core</div><div> The system it is building would have to be matched with the cm3 itself.</div><div> It might turn around at the cm3 point and use that cm3 to rebuild.</div><div><br clear="none"></div><div><br clear="none"></div><div>This is only a minor layering/scripting over what we already have.</div><div><br clear="none"></div><div>This configure might be written in portable sh or portable C/C++, but it doesn't have to do much.</div><div>The make step, boot1.py already generates makefiles, but that could be pushed into sh</div><div>or C/C++ if desired.</div><div><br clear="none"></div><div>Honestly, there is a problem that I just find sh very difficult to adopt for anything.</div><div>Python or C or C++ are much preferable to me.</div><div>This construction does delegate mostly to Modula-3, but for some bootstrapping.</div><div><br clear="none"></div><div>Still though, I still wonder about replacing the config files with libtool...</div><div>Generating Makefile.am from the m3makefiles..</div><div>and btw, we'd run "make -j" -- parallelism!</div><div><br clear="none"></div><div> - Jay</div><br clear="none"><br clear="none"><div class="yiv3270809950yqt8309995843" id="yiv3270809950yqtfd15508"><div>> To: wagner@elegosoft.com; m3devel@elegosoft.com<br clear="none">> From: adacore@marino.st<br clear="none">> Date: Sat, 25 Jun 2016 16:06:12 +0200<br clear="none">> Subject: Re: [M3devel] M3 Portabilbity, Installation, Distribution -- use Docker Containers for Easy Access?<br clear="none">> <br clear="none">> On 6/25/2016 2:24 PM, Olaf Wagner wrote:<br clear="none">> > Lurking in the shadows and reading all the recent mails about improving<br clear="none">> > the build system and seeing more and more steps 'backwards' to adapt<br clear="none">> > to C, autoconf, makefiles and more overcome tools and concepts, a<br clear="none">> > heretical thought comes to mind: Have you ever considered using docker<br clear="none">> > as a means to provide easy access and distribution of Modula-3?<br clear="none">> <br clear="none">> You mean Linux-only Docker?<br clear="none">> <br clear="none">> In general this concept would not be compatible with typical s/w build <br clear="none">> repositories used by various OS. If you went to a primary Docker <br clear="none">> distribution system, you're basically saying A) M3 is limited to Linux <br clear="none">> and B) It's distributed by third parties (you) only.<br clear="none">> <br clear="none">> At first glance, I'd say it's a bad idea.<br clear="none">> <br clear="none">> John<br clear="none">> <br clear="none">> ---<br clear="none">> This email has been checked for viruses by Avast antivirus software.<br clear="none">> https://www.avast.com/antivirus<br clear="none">> <br clear="none">> _______________________________________________<br clear="none">> M3devel mailing list<br clear="none">> M3devel@elegosoft.com<br clear="none">> https://m3lists.elegosoft.com/mailman/listinfo/m3devel<br clear="none"></div> </div></div></div></div></div><br clear="none"><div class="yiv3270809950yqt8309995843" id="yiv3270809950yqtfd91417">_______________________________________________<br clear="none">M3devel mailing list<br clear="none"><a rel="nofollow" shape="rect" ymailto="mailto:M3devel@elegosoft.com" target="_blank" href="mailto:M3devel@elegosoft.com">M3devel@elegosoft.com</a><br clear="none"><a rel="nofollow" shape="rect" target="_blank" href="https://m3lists.elegosoft.com/mailman/listinfo/m3devel">https://m3lists.elegosoft.com/mailman/listinfo/m3devel</a><br clear="none"></div><br clear="none"><br clear="none"></div> </div> </div> </div></div></div></div><br><br></div> </div> </div> </div></div></body></html>