2008/8/28 Patrick R. Michaud <[EMAIL PROTECTED]>: > On Thu, Aug 28, 2008 at 02:10:27PM +0200, Reini Urban wrote: >> Open problem: >> For language pbc's a new dir like script_dir or lib_dir/parrot/bin >> would be required. >> They could also pollute $(DESTDIR)@lib_dir@/parrot/library where the other >> pbc's are. >> The language group and op shared libs go to $(DESTDIR)@lib_dir@/parrot/dynext >> for sure. >> e.g. tclsh.pbc, APL.pbc, ... > > I'd be a bit surprised if the .pbc files went into dynext/ -- that doesn't > seem to match what currently exists there (which is all .so files on > my system).
Sure. My comment about the tclsh.pbc, APL.pbc, ... was referring to the language pbc's, not to the group and op shared libs. > At the moment I'm planning for language pbcs to go into > .../parrot/library/ so they can be easily accessed via > load_bytecode. I've found that in a dynamic environment like > Parrot there's very little difference between a language and > a library [1]. :-) That's probably the best, but we can also think of not installing that at all, and only install executables. But then the new pddxx_language_interop.pod at http://nopaste.snit.ch/13890 will have problems. exe cannot loaded from other languages, only pbc's. So each language will need its root namespace reserved for it's <lang>.pbc. We could thing of symlinking it to runtime/parrot/library at make languages, so language_interop can be tested. > Also, I wonder if any of this relates to RT #47992 ("'parrot foo' > automatically finds and invokes foo.pbc")? If foo.pbc is in parrot/library/foo.pbc then it will be found. The pbc library searchpath is only "." and "@lib_dir@/parrot/library". Also PARROT_RUNTIME can be defined in ENV to override the runtime prefix and therefore the library search path.. -- Reini Urban http://phpwiki.org/ http://murbreak.at/
