Allison Randal schrieb:
Will Coleda wrote:
It's important to keep in mind that for the most part, at least on
unix-related operating systems, executables for a particular language
will
simply be an 'ln -s' to /usr/bin/parrot (taking advantage of the $0
executable name information to set up certain configuration for the
runtime
environment).
I'm curious how you envision languages registering themselves for this
special treatment?
I'm assuming that when a language module is installed, it will not only
store its libraries in a lib directory, and its executables in a bin
directory, but also a small config file in some directory like
/etc/parrot/languages/. That would give the name of the language, a few
relevant paths, and probably some meta-information like the license of
the language module.
I don't like this idea of another language configuration file. We can do
without.
The name of the startup .pir/.pbc module is the same as registered via
compreg, which must be the same as the name of the language directory.
I want to call that now HLLNAME.
TODO: only unl
There are certain HLL's with multiple executables or different names.
tcl wants to be named tclsh, so it will be /usr/bin/parrot-tclsh.
Either symlinked to /usr/lib/parrot/library/tcl.pbc or as installable
via pbc_to_exe --install linked to install_config.fpmc.
bf has bf.pbc, bfc.pbc and bfco.pbc and parrot-bf, parrot-bfc and
parrot-bfco installables.
WMLScript has wmls2pir, wmls2pbc, wmlsd, wmlsi with its pbc's, but
there's also the main WMLScript.pbc.
Just the load_bytecode 'languages/WMLScript/src/WMLScript.pbc' is
forbidden in the wmls* scripts.
It must be load_bytecode 'WMLScript.pbc'
and 'WMLScript.pbc' must be generated to runtime/parrot/library/,
not in src.
This load_bytecode 'languages/..' problem is in eclectus, forth, lua,
PIR, tcl and WMLScript.
I'll fix that by generating these pbc's directly to
runtime/parrot/library/.
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
