<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'><div dir='ltr'>
Daniel, I don't understand you.<br>We have pretty good support for cross builds.<br>However it rests on underlying cross-compiler/linker though, and those are often not so easy to build/setup.<br>We use whatever gcc is in $PATH, it can be a cross compiler, and you can set $CM3_TARGET / $M3CONFIG to point to whatever target configuration.<br>If you don't want "gcc in $PATH" but instead want "target-gcc", that is easy and minor.<br>We could support e.g. $CM3_CC.<br><br>Probably it should be more like cm3 -target=foo.<br>And the quake/config/cm3 code should perhaps probe for foo-gcc.<br>Something like autoconf. But at each invocation, since you should be able to say cm3 -target=foo && cm3 -target=bar or even all at once cm3 -target=foo,bar.<br>
<br><br>cm3 knows about "all" targets.<br>It knows very little about any target, really.<br>But some.<br>I tried to remove its knowledge about jmpbuf size but so that failed.<br>This is mostly better than the typical gcc usage where you have to configure and build separate gcc (gcc, cc1plus, etc.) for each target.<br> (However binutils/ld/as are better now, you can perhaps configure for all targets at once.)<br> Of course, cm3cg is gcc, so it still has that problem. Yuck. This is yet another problem that a C-backend would fix -- no more target-specific cm3cg.<br><br><br>Much of the target-specific knowledge is in Quake/config files.<br>There is more than I would like, but it isn't a ton.<br>It is a less than it used to be, both in cm3 and the quake/config code.<br><br><br> - Jay<br><br><div><hr id="stopSpelling">Date: Thu, 16 Jun 2011 20:34:41 +0100<br>From: dabenavidesd@yahoo.es<br>To: m3devel@elegosoft.com; wagner@elegosoft.com; jay.krell@cornell.edu<br>Subject: Re: [M3devel] helo everyone - videotutorials for modula3<br><br><table border="0" cellpadding="0" cellspacing="0"><tbody><tr><td style="font:inherit" valign="top">Hi all:<br>but indeed if we were building such a cross-development environment like say eg I386_MINGW, else anything like that we would have several possible targets (for instance some application compiled under X Window and some others for native GUI, granted potentially the C compiler linker fits there) as AMD64_INTERIX, etc.<br>Tjis cases could create a problem to package everything in just one tar ball, it would be more a modular thing as you say, again I coincide that the cost of what we can host is better, but there are this issues we could somehow get into play. Anyway, it is maybe a cross-development issue rather than native issue, but it certainly begs some attention if I may say so.<br><br>Thanks in advance<br><br>--- El <b>jue, 16/6/11, Jay K <i><jay.krell@cornell.edu></i></b> escribió:<br><blockquote style="margin-left:5px;padding-left:5px"><br>De: Jay K <jay.krell@cornell.edu><br>Asunto: RE: [M3devel] helo everyone - videotutorials for modula3<br>Para: dabenavidesd@yahoo.es, "m3devel" <m3devel@elegosoft.com>, "Olaf" <wagner@elegosoft.com><br>Fecha: jueves, 16 de junio, 2011 13:27<br><br><div id="ecxyiv1044864033">
<style>
.ExternalClass #ecxyiv1044864033 .ecxyiv1044864033hmmessage P
{padding:0px;}
.ExternalClass #ecxyiv1044864033 .ecxyiv1044864033hmmessage
{font-size:10pt;font-family:Tahoma;}
</style>
<div dir="ltr">
rambly...<br><br>> > >> hing -- just the headers and<br>> > >> a list of symbols in libfoo.so=2C not the actual<br>> > code for libfoo.so.<br><br><br>I wasn't referring to "libm3.so" so much as "libc.so".<br>i.e. not stuff we build, but stuff we reference.<br><br>That is -- if you recall -- the thread "started" (I seemed to miss the start) bemoaning something about a dependency on postgres and postgres wasn't installed.<br>The postgres dependency should only be for building our postgres wrapper, not for installing anything.<br><br>On a private reply...apparently I left cminstall in the *.deb files, and I think that was an accident.<br>The original poster installed the .deb and ran cminstall.<br><br>As I said private and repeatedly pubically -- cminstall isn't very good at doing the very little it does.<br>And also, I did do the per-target work of finding where packages strongly tend to be installed, so that<br>the probing
around by cminstall is less useful. Granted...stuff can still be in a variety of places.<br><br>Even if, e.g. /usr/opt is "standard" in some packaging system (NetBSD?), user might still<br>manually install to /usr/local or $HOME or $HOME/foo or whatever.<br><br>Ultimately I guess I guess the config files can and should be user-edited upon install.<br>AND to that end, there should be a better separation between simple-somewhat-likely-to-be-user-edited content<br>and gnarlier-less-likely-to-be-edited, and the possibly-not-sure-it-exists-must-not-be-edited<br><br><br>By which..I don't know...maybe the files should be broken up more, like:<br><br> /cm3/bin/config/target/libraries (a text file, a quake snippet -- pick some extension) <br> /cm3/bin/config/target/c_compiler (ditto) <br> /cm3/bin/config/target/internal (ditto) <br> /cm3/bin/config/target/main? (ditto) <br><br> main would simply include(internal), c_compiler, libraries,
in some order <br>
<br><br>oops but there I went making things modular! :) <br><br><br>..and...really..I'm not going to do this, for multiple reasons.<br><br>The current code is already somewhat well factored into small toplevel files that include<br>other shared and "gnarlier" files.<br><br>It takes merely like<br><br>SYSTEM_LIBS = ...<br><br>in the toplevel file to trump the shared gnarly stuff.<br><br>We should possibly just put that in each file, commented out perhaps.<br><br>But even so, I don't like putting much of anything in I386_LINUX, AMD64_LINUX, PPC_LINUX, etc.<br>rather nicer to put stuff in Linux.common.<br><br> ..Jay<br><br><br><div>> Date: Thu, 16 Jun 2011 15:43:28 +0100<br>> From: dabenavidesd@yahoo.es<br>> To: m3devel@elegosoft.com; wagner@elegosoft.com<br>> Subject: Re: [M3devel] helo everyone - videotutorials for modula3<br>> <br>> Hi all:<br>> I think is just because of the project repository thing,a s In DEC SRC the vesta CM
system, and had a cache of the copies in the laboratories and compiled for local machines (but they did have the AST cached, see:<br>> ftp://apotheca.hpl.hp.com/pub/dec/SRC/research-reports/SRC-168.pdf<br>> <br>> I believe to help building large programs), I however don't know besides the test purposes where behind this specifically Juno-2, it seems they tests whether the configuration scheme was optimized to Juno µ-code programs, however still I don't think they necessarily did that but for another experiment of performance monitoring called PSpec used to monitor how was Juno-2 behaving in execution times mount also in Vesta in the JunoVM.<br>> <br>> BTW, if it doesn't matter what is the current working state of Juno-2 in Win32, this could be the most critical but appreciable piece between many others obviously more critical than it self.<br>> <br>> Thanks in advance<br>> <br>> --- El jue, 16/6/11, Olaf Wagner
<wagner@elegosoft.com> escribió:<br>> <br>> > De: Olaf Wagner <wagner@elegosoft.com><br>> > Asunto: Re: [M3devel] helo everyone - videotutorials for modula3<br>> > Para: m3devel@elegosoft.com<br>> > Fecha: jueves, 16 de junio, 2011 05:14<br>> > Quoting Mika Nystrom <mika@async.caltech.edu>:<br>> > <br>> > > Jay K writes:<br>> > > ...<br>> > >> Besides that=2C there's a certain dumbness.<br>> > >> Compiling and dynamic linking against libfoo.so<br>> > ought to require almost not=<br>> > >> hing -- just the headers and<br>> > >> a list of symbols in libfoo.so=2C not the actual<br>> > code for libfoo.so.<br>> > >> That is basically how compile/link on Windows<br>> > works. But maybe not elsewher=<br>> > >> e.<br>> > > ...<br>> > > <br>> > > SRC M3 used to work like
this: m3ship would ship only<br>> > the .a/.so, the .i3<br>> > > files, and some sort of symbol table. PM3<br>> > started shipping the sources,<br>> > > not sure why.<br>> > <br>> > I think the only reason is to have fully indexed and<br>> > referenced<br>> > source documentation via Reactor/CM3-IDE/m3browser.<br>> > <br>> > I don't really see how that is related to linking against<br>> > external<br>> > libraries though.<br>> > <br>> > Olaf<br>> > --Olaf Wagner -- elego Software Solutions GmbH<br>> > <br>> > Gustav-Meyer-Allee 25 / Gebäude 12, 13355<br>> > Berlin, Germany<br>> > phone: +49 30 23 45 86 96 mobile: +49 177 2345<br>> > 869 fax: +49 30 23 45 86 95<br>> > http://www.elegosoft.com |<br>> > Geschäftsführer: Olaf Wagner | Sitz: Berlin<br>> > Handelregister: Amtsgericht
Charlottenburg HRB 77719 |<br>> > USt-IdNr: DE163214194<br>> > <br>> > <br></div> </div>
</div></blockquote></td></tr></tbody></table></div> </div></body>
</html>