<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'><div>I agree and disagree.</div><div><br></div><div><br></div><div>Regarding Posix -- I think it did well for low level C.</div><div><br></div><div><br></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></div><div><br></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></div><div> </div><div>Quake was written in C.</div><div><br></div><div><br></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></div><div><br></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></div><div><br></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></div><div><br></div><div>I'm aware of Docker.</div><div><br></div><div><br></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></div><div> </div><div>I'm not sure it is relevant here.</div><div><br></div><div><br></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></div><div><br></div><div>I don't think C and autoconf/automake are clearly a step backward.</div><div><br></div><div><br></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></div><div><br></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></div><div><br></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></div><div><br></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></div><div><br></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></div><div><br></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></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></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></div><div><br></div><div>This is only a minor layering/scripting over what we already have.</div><div><br></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></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></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></div><div> - Jay</div><br><br><div>> To: wagner@elegosoft.com; m3devel@elegosoft.com<br>> From: adacore@marino.st<br>> Date: Sat, 25 Jun 2016 16:06:12 +0200<br>> Subject: Re: [M3devel] M3 Portabilbity, Installation, Distribution -- use Docker Containers for Easy Access?<br>> <br>> On 6/25/2016 2:24 PM, Olaf Wagner wrote:<br>> > Lurking in the shadows and reading all the recent mails about improving<br>> > the build system and seeing more and more steps 'backwards' to adapt<br>> > to C, autoconf, makefiles and more overcome tools and concepts, a<br>> > heretical thought comes to mind: Have you ever considered using docker<br>> > as a means to provide easy access and distribution of Modula-3?<br>> <br>> You mean Linux-only Docker?<br>> <br>> In general this concept would not be compatible with typical s/w build <br>> repositories used by various OS. If you went to a primary Docker <br>> distribution system, you're basically saying A) M3 is limited to Linux <br>> and B) It's distributed by third parties (you) only.<br>> <br>> At first glance, I'd say it's a bad idea.<br>> <br>> John<br>> <br>> ---<br>> This email has been checked for viruses by Avast antivirus software.<br>> https://www.avast.com/antivirus<br>> <br>> _______________________________________________<br>> M3devel mailing list<br>> M3devel@elegosoft.com<br>> https://m3lists.elegosoft.com/mailman/listinfo/m3devel<br></div> </div></body>
</html>