<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Hi all:<br>I got your point, but even after that the need for product-quality inter-opeartion with C code, specially, because everything else in the market is C, is desperately needed, we don't have some framework to actually using code from C-RT as is. I know DEC somehow lacked more effort towards producing for us that, although C interoperability was very good, they studied the problem for C and Modula-3, which is nice, and also I think they worked in their GEM compiler for Fortran, Cobol, C, .. so they should used basic concepts like 'program cell' for those compilers.<br>That said I know of an incremental code generator and linker for typeful programming languages for database machines, so I know producing some compiler target wouldn't be hard so much work like currently we had to even when there are many languages that we would match, say SQL, etc.
<br><br>Thanks in advance<br><br>--- El <b>dom, 20/5/12, Jay <i><jay.krell@cornell.edu></i></b> escribió:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>De: Jay <jay.krell@cornell.edu><br>Asunto: Re: [M3devel] more Debian packages?<br>Para: "Daniel Alejandro Benavides D." <dabenavidesd@yahoo.es><br>CC: "<hendrik@topoi.pooq.com>" <hendrik@topoi.pooq.com>, "m3devel" <m3devel@elegosoft.com>, "Jay K" <jay.krell@cornell.edu><br>Fecha: domingo, 20 de mayo, 2012 16:43<br><br><div id="yiv845438675"><div><div>No no no.</div><div>We will not have an explosion of targets like this. We hopefully will have a drastic reduction.</div><div>Processor: C or C++</div><div>Threads: pthreads or Win32 or maybe ucontext or setjmp</div><div>GUI: X Windows or Win32 or none or maybe other</div><div>Suspension: cooperative and probably no
other</div><div><br></div><div><br></div><div>If the right level of #ifdef and/or autoconf and/or libtool use can makes its way into the "object code", maybe just target completely. (imagine one C source distribution for ALL targets and what that requires).</div><div>We have rather replaced autoconf & libtool with our carefully researched & written quake code, for better & worse & I am torn as to if this is a good thing. Autoconf & libtool are slow & obscure but ubiquitous, get the job done, are actively maintained by others.</div><div><br></div><div><br> - Jay (briefly/pocket-sized-computer-aka-phone)</div><div><br>On May 19, 2012, at 11:32 AM, "Daniel Alejandro Benavides D." <<a rel="nofollow" ymailto="mailto:dabenavidesd@yahoo.es" target="_blank" href="/mc/compose?to=dabenavidesd@yahoo.es">dabenavidesd@yahoo.es</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div><table border="0" cellpadding="0"
cellspacing="0"><tbody><tr><td style="font:inherit;" valign="top">Hi all:<br>
I would want LINUX_I80_8Y or if you prefer LINUX_I_8Y,<br>
for instance to allow and or LINUX_I8086, etc LINUX_I387 <br>
For VAXen computers:<br>
VMS_VAX__<br>
for VAX Mini/Mainframe VMS_VAX9K or VMS_VAX11<br>
Alpha's: OSF_ALPHA<br>
For Unixes:<br>
FBSD-GENERIC_I_86___--<br>
To allow: FBSD-2_I386.MAX, OBSD-6_I_86.AMD64<br>
Also could be managed by Manufacturer Model code-name, like<br>
DEC_AQUARIUS or DEC_10000.<br>
<br>
Also if we are gonna take macro assembly for cross-platform distributions then, we would need something akin:<br>
NT_XASM-I_86___<br>
So to cross-assembly from C-RT to POSIX interoperability NT-I_86GNU (if such is supported in any appropriate version, Jay)<br><br>This would allow to compile CVSup at least is what one would like to<br>Thanks in advance<br><br> --- El <b>vie, 18/5/12, Jay K <i><<a rel="nofollow" ymailto="mailto:jay.krell@cornell.edu" target="_blank" href="/mc/compose?to=jay.krell@cornell.edu">jay.krell@cornell.edu</a>></i></b> escribió:<br><blockquote style="border-left:2px solid rgb(16, 16, 255);margin-left:5px;padding-left:5px;"><br>De: Jay K <<a rel="nofollow" ymailto="mailto:jay.krell@cornell.edu" target="_blank" href="/mc/compose?to=jay.krell@cornell.edu">jay.krell@cornell.edu</a>><br>Asunto: Re: [M3devel] more Debian packages?<br>Para: <a rel="nofollow" ymailto="mailto:hendrik@topoi.pooq.com" target="_blank" href="/mc/compose?to=hendrik@topoi.pooq.com">hendrik@topoi.pooq.com</a>, "m3devel" <<a rel="nofollow" ymailto="mailto:m3devel@elegosoft.com"
target="_blank" href="/mc/compose?to=m3devel@elegosoft.com">m3devel@elegosoft.com</a>><br>Fecha: viernes, 18 de mayo, 2012 16:50<br><br><div id="yiv845438675">
<style><!--
#yiv845438675 .yiv845438675hmmessage P
{
margin:0px;padding:0px;}
#yiv845438675 body.yiv845438675hmmessage
{
font-size:10pt;font-family:Tahoma;}
--></style><div><div dir="ltr">
Yes and yes.<br>LINUXLIBC6 and AMD64_LINUX can coexist -- different targets can coexist.<br>But "squeeze" vs. "wheezy" will both just be LINUXLIBC6.<br> <br> <br>Please try to use I386_LINUX.<br>I really want to stop this LINUXLIBC6 stuff...<br> <br> <br> You can share the source.<br> But we also have outputs in the source tree (unfortunately!).<br> You see -- Modula-3 build system ahead of its time at the time in putting each package's output separate from the source, but that is now not uncommon, and Modula-3 then falls down because at least by default, a multi-package source tree contains its outputs... Modula-3 does things better than most folks at the time, and now worse than everyone knows is ideal and that some folks do...<br> <br> <br> Do this to switch:<br> <br> ./do-cm3-all.py realclean <br> <br> - Jay<br> <br><div><div
id="yiv845438675SkyDrivePlaceholder"></div>> Date: Fri, 18 May 2012 16:56:49 -0400<br>> From: <a rel="nofollow" ymailto="mailto:hendrik@topoi.pooq.com" target="_blank" href="/mc/compose?to=hendrik@topoi.pooq.com"></a><a rel="nofollow" ymailto="mailto:hendrik@topoi.pooq.com" target="_blank" href="/mc/compose?to=hendrik@topoi.pooq.com">hendrik@topoi.pooq.com</a><br>> To: <a rel="nofollow" ymailto="mailto:m3devel@elegosoft.com" target="_blank" href="/mc/compose?to=m3devel@elegosoft.com"></a><a rel="nofollow" ymailto="mailto:m3devel@elegosoft.com" target="_blank" href="/mc/compose?to=m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>> Subject: [M3devel] more Debian packages?<br>> <br>> Having succeeded at producing a binary .deb packages for Debian squeeze <br>> (though I still have to try it out), I'm now looking at my other <br>> machines. I have a 32-bit Intel machine with wheeze (testing), and one <br>> that can run squeeze
(stable). All of them have access to the same <br>> NFS-mounted source tree. Is it practical to use the same tree for two <br>> different platforms (such as AMD64_LINUX and LINUXLIB6?) and will they <br>> be kept separate? Or do I need to clean it out or copy it?<br>> <br>> (by the way, I expect making packages for different Debian releases on <br>> the same hardware architecture will require a new source tree, or a <br>> cleaned-out one. In my case they'll
both be LINUXLIBC6)<br>> <br>> -- hendrik<br>> <br></div> </div></div>
</div></blockquote></td></tr></tbody></table></div></blockquote></div></div></blockquote></td></tr></table>