<div>Hi!</div><div><br /></div><div><br /></div><div><br /></div><div>  I think, best way "kill" even Phyton scripts and use only "native Modula-3 ecosystem".</div><div><br /></div><div><br /></div><div>Best regards, Victor Miasnikov</div><div><br /></div><div>16.07.2021, 12:30, "Jay K" <jayk123 at hotmail.com>:</div><blockquote><div dir="ltr">
<div style="color:rgb( 0 , 0 , 0 );font-family:'calibri' , 'helvetica' , sans-serif;font-size:12pt">
Hi. I've been wanting to say something like this for a while.
<div><br />
</div>
<div>But I'm not sure what exactly.</div>
<div><br />
</div>
<div>I know the autotools have problems.</div>
<div><br />
</div>
<div>They are slow.</div>
<div><br />
</div>
<div>They are "byzantine" (complicated, generating generators, etc.)</div>
<div><br />
</div>
<div>They aren't "Windows native".</div>
<div><br />
</div>
<div>Really, I get it. I personally do not know sh or m4 and suspect</div>
<div>they are not great languages. I don't really want to program in them, I think.</div>
<div><br />
</div>
<div>But they are also kinda amazing.</div>
<div>They provide value, a superset of part of our system.</div>
<div><br />
</div>
<div>They achieve a kinda amazing level of portability.</div>
<div><br />
</div>
<div>For example, I have only recently built a bunch of software on OSF/1.</div>
<div> You would probably be surprised.</div>
<div><br />
</div>
<div>It is true that software was mostly composed of "portable" C.</div>
<div><br />
</div>
<div>But it also had "portable build systems".</div>
<div>That work both consistently and on a fairly low common denominator Posix base.</div>
<div> Yes, it is true, I built and maybe used bash.</div>
<div> I built and certainly used GNU make.</div>
<div> (GNU tar is actually super important too, because of long paths.)</div>
<div> The "autotools" aren't the entire story.</div>
<div><br />
</div>
<div><br />
</div>
<div>The outliers were OpenSSH, OpenSSL, Perl, Git, and Vim, and to some extent zip, xz.</div>
<div>They all have different build systems and they were all more difficult to build as a result.</div>
<div>Including lack of support for out-tree-builds.</div>
<div><br />
</div>
<div>Perl and OpenSS? in particular do follow the cm3 pattern -- they have been specifically</div>
<div>ported to a fixed list of systems.</div>
<div><br />
</div>
<div>On one hand, I understand there is a circular dependency to avoid, but that does</div>
<div>not actually excuse the outliers, at all. The circular dependency is broken</div>
<div>in the autotools, clearly. Running autoconf requires Perl, but running its output does not.</div>
<div>It is a compiler, crude may be its input and output (more of a linker, perhaps).</div>
<div><br />
</div>
<div><br />
</div>
<div>I understand, they produce untested combinations on untested systems.</div>
<div><br />
</div>
<div>But given a set of reasonably well known factors:</div>
<div><br />
</div>
<div> Is feature X present? </div>
<div> Is feature Y present? </div>
<div> Is feature Z present?</div>
<div><br />
</div>
<div>for which you believe you can accept either answer, voila, portability to up to 8</div>
<div>systems, without knowing specifically about them ahead of time.</div>
<div><br />
</div>
<div><br />
</div>
<div>cmake is all the rage, but I still don't have a C++ compiler on OSF/1 that can compile it.</div>
<div>I have gcc 4.7.4, and I am close to having gcc 4.8, which should suffice.</div>
<div>(Gcc 4.8 is also the minimum gcc that can compile gcc 11...)</div>
<div><br />
</div>
<div>I am not sure, but I think speaks to portability.</div>
<div>Or maybe the need to move on from very old systems?</div>
<div><br />
</div>
<div>ok, that all said, what to do with Modula-3?</div>
<div><br />
</div>
<div>The autotools are acceptably fast imho for one-off builds, but there is a certain obvious</div>
<div>use that I am relucant to implement.</div>
<div><br />
</div>
<div>That is, I could see quite easily, distributing the entire system, as C, fully</div>
<div>buildable with the traditional configure + make + make install.</div>
<div><br />
</div>
<div>We have just cm3 close to that: make + cp. But the Makefile is somewhat</div>
<div>system-specific, and while it is fairly simple, it is still unusual.</div>
<div><br />
</div>
<div>The system could be easy to build "from scratch" as any boring portable C codebase.</div>
<div><br />
</div>
<div>But once you have a working Modula-3 compiler, the performance, of a straightforward</div>
<div>implemenatation -- generate per-package small configure.ac, Makefile.am that looks very much like</div>
<div>m3makefile, run autoconf, automake, make...unless incrementally really works out, would</div>
<div>spend too long doing the simple things like finding the C compiler.</div>
<div><br />
</div>
<div>Perhaps it is just an incrementality matter. I am not sure. I do too many clean builds..because</div>
<div>the compiler itself is not a factor in compiler incrementality..maybe fix that?</div>
<div><br />
</div>
<div><br />
</div>
<div>As well, there is libtool.</div>
<div>For exapmle, to this day, I haven't used AIX much and didn't run Modula-3 on it.</div>
<div>AIX remains a fairly in-use in-development Unix.</div>
<div>We kinda should support it.</div>
<div>It ought to be easy.</div>
<div>But I am pretty sure it has yet another set of linker switches.</div>
<div><br />
</div>
<div><br />
</div>
<div>If we used libtool, or even cmake, we'd get the support for "free".</div>
<div>It would work, and be maintained, by others.</div>
<div><br />
</div>
<div>But yet libtool is also kinda gross and maybe slow.</div>
<div><br />
</div>
<div>So I am not sure what to do.</div>
<div><br />
</div>
<div>It'd be great I think to stop maintaining *most* of our build system.</div>
<div> It isn't a ton of code, but it also does not auto-adapt to systems we haven't seen.</div>
<div> You know, people have Posix-ish OS/2. DragonflyBSD. The list grows gradually forever.</div>
<div><br />
</div>
<div>We should not know about compiler switches and linker switches, nor</div>
<div>have a mess for probing for them.</div>
<div><br />
</div>
<div>Something like, kinda like cminstall but more automatic, run configure</div>
<div>once "for the system" save that way, or extract some information from it,</div>
<div>and efficiently reuse it.</div>
<div>?</div>
<div><br />
</div>
<div>Leaving Windows as a special case, sure, one system is maintainable.</div>
<div> Is that cheating?</div>
<div> Is that a reason to favor cmake?</div>
<div><br />
</div>
<div>Or maybe, that is almost the answer: Maintain Windows and Linux and drop all of the rest?</div>
<div>Oh and Mac? BSD???</div>
<div><br />
</div>
<div>I don't know but it has been bugging me a long time.</div>
<div>Every time I read a compiler or linker man page, I think this is work best delegated</div>
<div>to another project somehow.</div>
<div><br />
</div>
<div>Maybe generating small configure.ac+Makefile.am per package isn't so bad, maybe</div>
<div>the incrementality works out.</div>
<div><br />
</div>
 - Jay<br />
</div>
</div>
,<p>_______________________________________________<br />M3devel mailing list<br /><a href="mailto:M3devel@elegosoft.com" target="_blank">M3devel@elegosoft.com</a><br /><a href="https://m3lists.elegosoft.com/mailman/listinfo/m3devel" target="_blank">https://m3lists.elegosoft.com/mailman/listinfo/m3devel</a><br /></p></blockquote>