<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> This is a bit long and out of order, sorry. </div><div>Simple story is for us to get out of the platform-specific build system maintenance business, and reuse larger portability from other projects.</div><div><br></div><div><br></div><div><br></div><div> I've been wrestling with this in my head a long while. </div><div><br></div><div><br></div><div> - I don't like maintaining the config files. </div><div> It is hard to be an expert on dynamic linking across "many" operating </div><div> systems, linkers, versions. </div><div><br></div><div><br></div><div> - I don't like that for example an AIX port remains absent.</div><div> And now I see AIX doesn't have $ORIGIN.</div><div><br></div><div><br></div><div> - It bothers me just slightly that we aren't portable</div><div> to the older systems that lack $ORIGIN.</div><div><br></div><div><br></div><div> $ORIGIN is nice if you are redistributing binaries, </div><div> that will be moved around, but it was never needed </div><div> for self-built software, or software installed to </div><div> an agreed upon place, and it isn't supported in setuid or such</div><div> programs. </div><div><br></div><div> (Aside -- and remember how bad it used to be?</div><div> We used to distribute binaries with random hardcoded paths, </div><div> and advise people to set LD_LIBRARY_PATH. Even for stuff people</div><div> self-built, it wasn't good. So I did improve things </div><div> but I don't think it is worth us doing ourselves.) </div><div><br></div><div><br></div><div> - Our current bootstrap/cross-build story isn't automated enough. </div><div> And then, what should it look like? </div><div><br></div><div><br></div><div> - Generating cmake or autoconf/automake/libtool input provides some potential answers. </div><div><br></div><div> I'd really like to delegate to folks that did and will continue to port pretty much everywhere. </div><div> Sometimes I think, hey, we can just do what we need ourselves, but then I see how </div><div> much gnarly system-specific knowledge autotools/cmake deliver nicely to their users. </div><div><br></div><div> </div><div> I had a mental stumbling block for years with cmake/autotools but finally </div><div> got over it. I have prototyped some simple uses, both with recursive </div><div> make and non-recursive make. </div><div><br></div><div><br></div><div> configure is a bit slow, but we'd have a very minimal one.</div><div> The resulting make invocations are ok. </div><div><br></div><div><br></div><div> I can almost just generate makefiles myself, but then for example</div><div> I don't know much about "install". cmake/automake provide me "install"</div><div> with me knowing nothing. </div><div><br></div><div><br></div><div> I don't really want to be an expert in make, compiler flags, linker flags,</div><div> Posix portability gotchas, etc. -- ok maybe at the libc/m3core level, but</div><div> not so much as the make/sed/awk/sh level. </div><div><br></div><div><br></div><div> There are a few details of autoconf/cmake/libtool I don't like, where the Modula-3</div><div> build system is clearly and simply superior. And other areas where I'm not</div><div> sure what is ideal.</div><div><br></div><div><br></div><div> Where Modula-3 is clearly superior in that in producing static and dynamic</div><div> libraries, it only ever compiles once. cmake and libtool are pretty keen</div><div> on compiling everything twice -- even with identical command lines.</div><div><br></div><div><br></div><div> Where I'm not sure is our probing for libraries and the build_standalone feature.</div><div> I think if we did things a little different/better, we wouldn't even have cm3</div><div> be standalone.</div><div><br></div><div><br></div><div> I very much want to offer to users the:</div><div> tar xf cm3...</div><div> cd cm3... </div><div> configure </div><div> make </div><div> make install </div><div> </div><div> </div><div> sort of experience. </div><div><br></div><div><br></div><div> There are slight difficulties. </div><div> configure probes the C compiler for what it produces.</div><div> Let's ignore C-backend and LLVM for now and consider cm3cg.</div><div><br></div><div><br></div><div> The likely best bootstrap format is assembly source. Like the 3.6 release. </div><div> For just cm3/m3core/libm3, or the entire system? </div><div><br></div><div><br></div><div> So configure probing vs. having on hand possibly just one assembly source is a bit of a misfit. </div><div><br></div><div><br></div><div> Perhaps configure would be tailored to hardcode what the distribution contains. </div><div><br></div><div><br></div><div> Or perhaps the distribution would contain "everything" and configure would pick the right one. </div><div> It is obviously wasteful, but these days maybe ok, and the result easier for people to install.</div><div><br></div><div><br></div><div> The C generating backend doesn't fix this much or entirely, since the C is still target-specific.</div><div> Maybe we can fold the C down to just a few platforms, and then the idea of one cross-platform distribution</div><div> might work. Maybe eventually the generated C can speak in "integer" and array/struct references, instead</div><div> of front-end computed offsets, but that is a ways off. </div><div><br></div><div><br></div><div> autotools/libtool also solve that problem where non-shipped binaries don't run. </div><div> Something we have hacked on by sprinkling build_standalone around. </div><div> I'm not sure if cmake fixes this. </div><div><br></div><div><br></div><div> I'm not sure they solve it the way I want though -- I'd like to have the uninstalled</div><div> paths hardcoded, then relink or otherwise binary edit in install. </div><div><br></div><div><br></div><div> One thing I need to study a bit more is how to install all the extra stuff to the pkg directories.</div><div><br></div><div> As well,...so many things... we have this structure: </div><div> bin/foo</div><div> lib/foo.so (did I do this? No matter, the layout is wierd w/o it.)</div><div> pkg/foo/TARGET/foo.so </div><div><br></div><div><br></div><div> I have always found it a little suspicious that binaries have implicit TARGET</div><div> but pkgs have explicit TARGET. I somewhat pine for a layout that can accomodiate</div><div> all targets including the bin directory.</div><div><br></div><div><br></div><div> I suppose if bin and lib are what run, and pkg is only for building, this accomodates</div><div> unshipped cross builds nicely. But ideally you could have a runnable PPC_DARWIN/I386_DARWIN/AMD664_DARWIN</div><div> system all in structure (caveat that PPC_DARWIN doesn't work in Rosetta because of our</div><div> preemptive suspend -- cooperative suspend would fix that.) </div><div><br></div><div><br></div><div> - Jay</div><br><br><br><br><div><hr id="stopSpelling">From: hosking@purdue.edu<br>To: jay.krell@cornell.edu<br>CC: m3devel@elegosoft.com<br>Subject: Re: [M3devel] naming convention unix vs. grumpyunix?<br>Date: Wed, 22 Jun 2016 21:19:12 +0000<br><br>
<div>Why import dependencies on make and automake?<br>
<br>
Sent from my iPad</div>
<div><br>
On Jun 22, 2016, at 9:41 PM, Jay K <<a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>> wrote:<br>
<br>
</div>
<blockquote>
<div><style><!--
.ExternalClass .ecxhmmessage P {
padding:0px;
}
.ExternalClass body.ecxhmmessage {
font-size:12pt;
font-family:Calibri;
}
--></style>
<div dir="ltr">I propose making unix match grumpyunix and removing grumpyunix.
<div><br>
</div>
<div>There is slight upside and should be no downside.</div>
<div><br>
</div>
<div>The upside is that various tools -- make and automake -- know that .s is assembly and will assemble it.</div>
<div><br>
</div>
<div>Is it a downside for base name to change foo.m3 => foo_m.s/foo_m.o vs. foo.m3 => foo.ms/foo.mo?</div>
<div><br>
</div>
<div>I expect everything will just work.</div>
<div><br>
</div>
<div> - Jay</div>
<div><br>
</div>
<div><br>
<br>
<br>
</div>
</div>
</div>
</blockquote>
<blockquote>
<div><span>_______________________________________________</span><br>
<span>M3devel mailing list</span><br>
<span><a href="mailto:M3devel@m3lists.elegosoft.com">M3devel@m3lists.elegosoft.com</a></span><br>
<span><a href="https://m3lists.elegosoft.com/mailman/listinfo/m3devel" target="_blank">https://m3lists.elegosoft.com/mailman/listinfo/m3devel</a></span><br>
</div>
</blockquote></div> </div></body>
</html>