On Thu, Aug 28, 2008 at 11:09 AM, Reini Urban <[EMAIL PROTECTED]> wrote:
> 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.
Right. We have to (eventually) install the pbcs, no matter if we also
install the exes for convenience.
> So each language will need its root namespace reserved for it's <lang>.pbc.
While it would help, there's no guarantee that namespace in PBC
matches path on filesystem.
> We could thing of symlinking it to runtime/parrot/library
> at make languages, so language_interop can be tested.
Are symlinks usable wherever we might install?
>> 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..
I had always thought that the compiler/compreg opcode would eventually
be extended to load the library we needed for language interop; If
not, I'm not sure there's much point in keeping the ability to
register compilers, is there? If someone wants to use the tcl
compiler, they need to know to load the bytecode first anyway.
> --
> Reini Urban
> http://phpwiki.org/ http://murbreak.at/
>
--
Will "Coke" Coleda
