Just came across an interesting quirk with the current usage of ICU--if you do it, you can't run parrot unless your current directory is the base parrot directory. Trying it from elsewhere throws a "string_set_data_directory: ICU data files not found" error.
Symlinking parrot's blib/ dir into the current dir works as a workaround, but we need to do something a bit more permanent. (If this means we need to work on an actual functioning install target, well... that's OK too)
You can tell it to find its data files with something like this:
perl Configure.pl --icudatadir="`pwd`/blib/lib/icu/2.6.1"
(that will make it use an absolute path).
By default it uses a relative path. The upside of a relative path is that you can move your whole source directory to a new location and it will still look in the "right" place; the downside is that you have to run from inside that directory. With an absolute path, it's the opposite. Once we are install-ing, it won't be a problem, but meanwhile you can choose which you like better.
(Note: This location is certainly settable at runtime--it's just a matter of teaching a new command-line paramter to parrot. Currently the path gets flowed into a #define in config.h called DEFAULT_ICU_DATA_DIR, so it has been named in preparation for being overridden at runtime, and just treating the config'd value as a fallback.)
BTW, I think we currently have the same problem with the "runtime" dir for finding dynamic extensions.
Is there yet a way (or really, an easy way) to access parrot's config's at runtime from inside the parrot code? I know we have library/config.fpmc, but I didn't know if anything was reading this from inside the parrot core. Or alternatively, should parrot have a separate (smaller) config file for parameters like these that it will always have to read, so that it doesn't pull in the full config on every run?
JEff
