[M3devel] M3devel Digest, Vol 56, Issue 22

Mon Jun 20 19:52:24 CEST 2011

I also think this is a non- obvious problem.

in windows, there is the registry, which is al wasy the same path, and
indicates the actual path of the files, does a facility like this exist in
ubuntu?

what about:

$ which postgres

does that yield good results?

2011/6/17 <m3devel-request at elegosoft.com>

> Send M3devel mailing list submissions to
>        m3devel at elegosoft.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
> or, via email, send a message with subject or body 'help' to
>        m3devel-request at elegosoft.com
>
> You can reach the person managing the list at
>        m3devel-owner at elegosoft.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of M3devel digest..."
>
>
> Today's Topics:
>
>   1. Re: helo everyone - videotutorials for modula3 (Jay K)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 16 Jun 2011 23:26:45 +0000
> From: Jay K <jay.krell at cornell.edu>
> Subject: Re: [M3devel] helo everyone - videotutorials for modula3
> To: <dabenavidesd at yahoo.es>, m3devel <m3devel at elegosoft.com>, Olaf
>        <wagner at elegosoft.com>
> Message-ID: <COL101-W58C35DFF622F6A5810F33EE66A0 at phx.gbl>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
>  > Anyway I think that is quite obvious if you want to link other libs
>
> You mean, like, to link to /usr/lib/libpostgres.so vs.
> /usr/local/lib/libpostgres.so vs. /home/jay/lib/libpostgres.so?
> Yeah, that is a problem. No good solution.
> Build-from-source is a solution, but not a good one.
> There's "origin", /etc/ld.so.conf, LD_LIBRARY_PATH, full paths in the
> executable.
> All are used, all have very significant advantages and disadvantages.
> I don't believe anyone has solved this problem.
> But I'm sure plenty of people believe they have.
>
>
>  - Jay
>
> Date: Fri, 17 Jun 2011 00:11:00 +0100
> From: dabenavidesd at yahoo.es
> To: m3devel at elegosoft.com; wagner at elegosoft.com; jay.krell at cornell.edu
> Subject: Re: [M3devel] helo everyone - videotutorials for modula3
>
> Hi all:
> yeah, you are correct the main problem might solved, but I was referring to
> was to the packaging in those cases where several implementations (not
> really Modula-3) might be available.
>
> CM problems that might have been solved too, I don't quite understand yet
> them as you. Sorry my ignorance if so. Anyway I think that is quite obvious
> if you want to link other libs you might want another model of
> pre-built-binaries or as you marked make everything compilation dependent
> procedures, which is something contrary to easy install and play setup
> (smarter developer, maybe individual packages for traditional users, that
> is, no geeks or both of them if could be fixed in the compiler setting)
> sense if I may say so.
>
> Thanks in advance
>
> --- El jue, 16/6/11, Jay K <jay.krell at cornell.edu> escribi?:
>
> De: Jay K <jay.krell at cornell.edu>
> Asunto: RE: [M3devel] helo everyone - videotutorials for modula3
> Para: dabenavidesd at yahoo.es, "m3devel" <m3devel at elegosoft.com>, "Olaf" <
> wagner at elegosoft.com>
> Fecha: jueves, 16 de junio, 2011 17:10
>
>
>
>
>
> Daniel, I don't understand you.
> We have pretty good support for cross builds.
> However it rests on underlying cross-compiler/linker though, and those are
> often not so easy to build/setup.
> 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.
> If you don't want "gcc in $PATH" but instead want "target-gcc", that is
> easy and minor.
> We could support e.g. $CM3_CC.
>
> Probably it should be more like cm3 -target=foo.
> And the quake/config/cm3 code should perhaps probe for foo-gcc.
> 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.
>
>
>
> cm3 knows about "all" targets.
> It knows very little about any target, really.
> But some.
> I tried to remove its knowledge about jmpbuf size but so that failed.
> This is mostly better than the typical gcc usage where you have to
> configure and build separate gcc (gcc, cc1plus, etc.) for each target.
>  (However binutils/ld/as are better now, you can perhaps configure for all
> targets at once.)
>  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.
>
>
> Much of the target-specific knowledge is in Quake/config files.
> There is more than I would like, but it isn't a ton.
> It is a less than it used to be, both in cm3 and the quake/config code.
>
>
>  - Jay
>
> Date: Thu, 16 Jun 2011 20:34:41 +0100
> From: dabenavidesd at yahoo.es
> To: m3devel at elegosoft.com;
>  wagner at elegosoft.com; jay.krell at cornell.edu
> Subject: Re: [M3devel] helo everyone - videotutorials for modula3
>
> Hi all:
> 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.
> 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.
>
> Thanks in advance
>
> --- El jue, 16/6/11, Jay K <jay.krell at cornell.edu> escribi?:
>
> De: Jay K <jay.krell at cornell.edu>
> Asunto: RE: [M3devel] helo everyone - videotutorials for modula3
> Para: dabenavidesd at yahoo.es, "m3devel" <m3devel at elegosoft.com>, "Olaf" <
> wagner at elegosoft.com>
> Fecha: jueves, 16 de junio, 2011 13:27
>
>
>
>
>
> rambly...
>
> > > >> hing -- just the headers and
> > > >> a list of symbols in libfoo.so=2C not the actual
> > > code for libfoo.so.
>
>
> I wasn't referring to "libm3.so" so much as "libc.so".
> i.e. not stuff we build, but stuff we reference.
>
> 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.
> The postgres dependency should only be for building our postgres wrapper,
> not for installing anything.
>
> On a private reply...apparently I left cminstall in the *.deb files, and I
> think that was an accident.
> The original poster installed the .deb and ran cminstall.
>
> As I said private and repeatedly pubically -- cminstall isn't very good at
> doing the very little it does.
> And also, I did do the per-target work of finding where packages strongly
> tend to be installed, so that
> the probing
>  around by cminstall is less useful. Granted...stuff can still be in a
> variety of places.
>
> Even if, e.g. /usr/opt is "standard" in some packaging system (NetBSD?),
> user might still
> manually install to /usr/local or $HOME or $HOME/foo or whatever.
>
> Ultimately I guess I guess the config files can and should be user-edited
> upon install.
> AND to that end, there should be a better separation between
> simple-somewhat-likely-to-be-user-edited content
> and gnarlier-less-likely-to-be-edited, and the
> possibly-not-sure-it-exists-must-not-be-edited
>
>
> By which..I don't know...maybe the files should be broken up more, like:
>
>  /cm3/bin/config/target/libraries (a text file, a quake snippet -- pick
> some extension)
>  /cm3/bin/config/target/c_compiler (ditto)
>  /cm3/bin/config/target/internal (ditto)
>  /cm3/bin/config/target/main? (ditto)
>
>  main would simply include(internal), c_compiler, libraries,
>  in some order
>
>
>
> oops but there I went making things modular! :)
>
>
> ..and...really..I'm not going to do this, for multiple reasons.
>
> The current code is already somewhat well factored into small toplevel
> files that include
> other shared and "gnarlier" files.
>
> It takes merely like
>
> SYSTEM_LIBS = ...
>
> in the toplevel file to trump the shared gnarly stuff.
>
> We should possibly just put that in each file, commented out perhaps.
>
> But even so, I don't like putting much of anything in I386_LINUX,
> AMD64_LINUX, PPC_LINUX, etc.
> rather nicer to put stuff in Linux.common.
>
>  ..Jay
>
>
> > Date: Thu, 16 Jun 2011 15:43:28 +0100
> > From: dabenavidesd at yahoo.es
> > To: m3devel at elegosoft.com; wagner at elegosoft.com
> > Subject: Re: [M3devel] helo everyone - videotutorials for modula3
> >
> > Hi all:
> > 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:
> > ftp://apotheca.hpl.hp.com/pub/dec/SRC/research-reports/SRC-168.pdf
> >
> >  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.
> >
> > 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.
> >
> > Thanks in advance
> >
> > --- El jue, 16/6/11, Olaf Wagner
>  <wagner at elegosoft.com> escribi?:
> >
> > > De: Olaf Wagner <wagner at elegosoft.com>
> > > Asunto: Re: [M3devel] helo everyone - videotutorials for modula3
> > > Para: m3devel at elegosoft.com
> > > Fecha: jueves, 16 de junio, 2011 05:14
> > > Quoting Mika Nystrom <mika at async.caltech.edu>:
> > >
> > > > Jay K writes:
> > > > ...
> > > >> Besides that=2C there's a certain dumbness.
> > > >> Compiling and dynamic linking against libfoo.so
> > > ought to require almost not=
> > > >> hing -- just the headers and
> > > >> a list of symbols in libfoo.so=2C not the actual
> > > code for libfoo.so.
> > > >> That is basically how compile/link on Windows
> > > works. But maybe not elsewher=
> > > >> e.
> > > > ...
> > > >
> > > > SRC M3 used to work like
>  this: m3ship would ship only
> > > the .a/.so, the .i3
> > > > files, and some sort of symbol table.  PM3
> > > started shipping the sources,
> > > > not sure why.
> > >
> > > I think the only reason is to have fully indexed and
> > > referenced
> > > source documentation via Reactor/CM3-IDE/m3browser.
> > >
> > > I don't really see how that is related to linking against
> > > external
> > > libraries though.
> > >
> > > Olaf
> > > --Olaf Wagner -- elego Software Solutions GmbH
> > >
> > >    Gustav-Meyer-Allee 25 / Geb?ude 12, 13355
> > > Berlin, Germany
> > > phone: +49 30 23 45 86 96  mobile: +49 177 2345
> > > 869  fax: +49 30 23 45 86 95
> > >    http://www.elegosoft.com |
> > > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> > > Handelregister: Amtsgericht
>  Charlottenburg HRB 77719 |
> > > USt-IdNr: DE163214194
> > >
> > >
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mail.elegosoft.com/pipermail/m3devel/attachments/20110616/8f0ac803/attachment.html
> >
>
> ------------------------------
>
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
>
>
> End of M3devel Digest, Vol 56, Issue 22
> ***************************************
>

-- 
312-444-2124
301-578-7884
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110620/51f7eba7/attachment-0001.html>