<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'>Not really.<div><br></div><div>My goal is to be close as possible to:</div><div> tar xf foo.tar.gz </div><div> mkdir bar # optional </div><div> cd bar # or foo </div><div> ../foo/configure </div><div> make </div><div> sudo make install </div><div><br></div><div>Nagging questions: </div><div> Is there one foo.tar.gz for everyone and autoconf picks the right part of it, or people pick the "correct" one for their system. </div><div><br></div><div> Is there a few such files -- target.tar.gz, the-rest-m3.tar.gz, maybe m3cc.tar.gz -- this is how 3.6 was structured </div><div> Back then quake was written in C however, not sure it matters. </div><div><br></div><div> Do we first build cm3 and then the rest of the system using it, or do we just use "make" to build everything. </div><div><br></div><div>I can imagine how to build everything from assembly using autoconf/libtool/make, but I kinda only want to do that only if cm3 also reuses the same infrastructure. Sometimes I also think of giving up on dynamic linking, since that is one of the bigger thorns.</div><div><br></div><div><br></div><div> - Jay</div><div><br><br><div><hr id="stopSpelling">From: dmuysers@hotmail.com<br>To: jay.krell@cornell.edu; hosking@purdue.edu<br>CC: m3devel@elegosoft.com<br>Subject: Re: [M3devel] naming convention unix vs. grumpyunix?<br>Date: Thu, 23 Jun 2016 08:33:00 +0200<br><br>
<style><!--
.ExternalClass .ecxhmmessage P {
padding:0px;
}
.ExternalClass body.ecxhmmessage {
font-size:12pt;
font-family:Calibri;
}
--></style>
<div dir="ltr">
<div style="FONT-SIZE:12pt;FONT-FAMILY:'Arial';COLOR:#000000;">
<div>Did you ever consider <a href="http://0install.net/" target="_blank">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=""><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="ecxstopSpelling">
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 .ecxexternalclass .ecxhmmessage p {
padding:0px;
}
.ExternalClass .ecxexternalclass 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>
<BR><hr>
_______________________________________________<br>M3devel mailing
list<br>M3devel@elegosoft.com<br>https://m3lists.elegosoft.com/mailman/listinfo/m3devel<br></div></div></div></div></div> </div></body>
</html>