<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'>
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></body>
</html>