<HTML><HEAD>
<STYLE><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></STYLE>
</HEAD>
<BODY class=hmmessage dir=ltr>
<DIV dir=ltr>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: 'Arial'; COLOR: #000000">
<DIV>Did you ever consider <A href="http://0install.net/">0install</A> as a
means of distribution?</DIV>
<DIV
style='FONT-SIZE: small; TEXT-DECORATION: none; FONT-FAMILY: "Calibri"; FONT-WEIGHT: normal; COLOR: #000000; FONT-STYLE: normal; DISPLAY: inline'>
<DIV style="FONT: 10pt tahoma">
<DIV> </DIV>
<DIV style="BACKGROUND: #f5f5f5">
<DIV style="font-color: black"><B>From:</B> <A title=jay.krell@cornell.edu
href="mailto:jay.krell@cornell.edu">Jay K</A> </DIV>
<DIV><B>Sent:</B> Thursday, June 23, 2016 2:38 AM</DIV>
<DIV><B>To:</B> <A title=hosking@purdue.edu
href="mailto:hosking@purdue.edu">Hosking, Antony L</A> </DIV>
<DIV><B>Cc:</B> <A title=m3devel@elegosoft.com
href="mailto:m3devel@elegosoft.com">m3devel</A> </DIV>
<DIV><B>Subject:</B> Re: [M3devel] naming convention unix vs.
grumpyunix?</DIV></DIV></DIV>
<DIV> </DIV></DIV>
<DIV
style='FONT-SIZE: small; TEXT-DECORATION: none; FONT-FAMILY: "Calibri"; FONT-WEIGHT: normal; COLOR: #000000; FONT-STYLE: normal; DISPLAY: inline'>
<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> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>I've been wrestling with this in my head a long while. </DIV>
<DIV> </DIV>
<DIV> </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> </DIV>
<DIV> </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> </DIV>
<DIV> </DIV>
<DIV>- It bothers me just slightly that we aren't portable</DIV>
<DIV> to the older systems that lack $ORIGIN.</DIV>
<DIV> </DIV>
<DIV> </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> </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> </DIV>
<DIV> </DIV>
<DIV>- Our current bootstrap/cross-build story isn't automated enough. </DIV>
<DIV> And then, what should it look like? </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>- Generating cmake or autoconf/automake/libtool input provides some
potential answers. </DIV>
<DIV> </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> </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> </DIV>
<DIV> </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> </DIV>
<DIV> </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> </DIV>
<DIV> </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> </DIV>
<DIV> </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> </DIV>
<DIV> </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> </DIV>
<DIV> </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> </DIV>
<DIV> </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> </DIV>
<DIV> </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> </DIV>
<DIV> </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> </DIV>
<DIV> </DIV>
<DIV>So configure probing vs. having on hand possibly just one assembly source
is a bit of a misfit. </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>Perhaps configure would be tailored to hardcode what the distribution
contains. </DIV>
<DIV> </DIV>
<DIV> </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> </DIV>
<DIV> </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> </DIV>
<DIV> </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> </DIV>
<DIV> </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> </DIV>
<DIV> </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> </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> </DIV>
<DIV> </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> </DIV>
<DIV> </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> </DIV>
<DIV> </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> </DIV>
<DIV>There is slight upside and should be no downside.</DIV>
<DIV> </DIV>
<DIV>The upside is that various tools -- make and automake -- know that .s is
assembly and will assemble it.</DIV>
<DIV> </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> </DIV>
<DIV>I expect everything will just work.</DIV>
<DIV> </DIV>
<DIV>- Jay</DIV>
<DIV> </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>
<P>
<HR>
_______________________________________________<BR>M3devel mailing
list<BR>M3devel@elegosoft.com<BR>https://m3lists.elegosoft.com/mailman/listinfo/m3devel<BR></DIV></DIV></DIV></BODY></HTML>