Leopold Toetsch (via RT) wrote:
3) "make install" creates src/parrot_config_install.c and links that into parrot_install$EXE, which during installation becomes .../bin/parrot$EXE. With this step we get rid of the problem with runtime vs build directory library usage.
Done (rev 8028), with slightly different files:
installable_parrot$EXE links with src/install_config.o
and
installable_parrot$EXE is installed as $PREFIX/bin/parrot$EXE
This step can be verified (after a make test has run) by:
./parrot t/pmc/config_2.pir # build_dir
./installable_parrot t/pmc/config_2.pir # --prefix dir
and after "make install"
$PREFIX/bin/parrot t/pmc/config_2.pir # same
(The test prints the --prefix pathh from parrot's builtin config hash.)
See also this test, how to currently access the runtime prefix (and possibly other config items).
More of this TODO ticket:
4) at program start the frozen config string gets thawed and we populate appropriate namespaces[2] with hash entries. Language folks and our fearless leader may please define the term appropriate :)
5) along with bringing the config online, some cleanup and renaming wouldn't harm e.g. "iv" vs "opcode_t", "intvalsize" vs "intsize" vs "opcode_t_size" ...
6) the config information could be available as attributes of the respective namespace:
ns = getclass "ParrotInterpreter" PINTVAL_size = ns."INTVAL_size" # getattribute shortcut
or with global namespace ops
PINTVAL_size = find_global "ParrotInterpreter", "INTVAL_size"
Comments, improvements, takers welcome, leo
[1] w/o Python quirks
>>> sys.maxint = 2 >>> sys.maxint 2
[2] a remark about namespaces
We currently have:
/ (namespace root) __parrot_core ... MMD multi subs Integer Float .... Parrot PMC class namespaces
The PMC class namespaces should probably reside under "__parrot_core" to get rid of the namespace pollution. Or alternatively, we prepend two underscores:
/ __parrot_core __ParrotInterpreter aka __sys __ParrotIO aka __io
