Re: pdd19_pir.pod: See C<docs/imcc/macros.pod>

["Reini Urban" <rurban@x-ray.at>]

2008/8/28 Patrick R. Michaud <pmichaud@pobox.com>:
> 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/