Dan Sugalski wrote:3) Parrot itself (the main executable) has a static, global 1K buffer in it that starts and ends with some recognizable string (like, say, "***+++***START|" and "|END***+++***") so we can find it and overwrite the contents if the library gets moved, for use on platforms where the only way to put a path in is to stick it statically in the executable.
That's pretty disgusting, but I don't know that I have a better idea.
It's yucky, but it matches what's done for dynamic libs, at least on some platforms. (That is, at build-time a library gets its path-where-I'll-be-installed compiled into it, and apps linked against that lib copy that path into themselves, so that at runtime the dynamic linker searches that location, in addition to standard locations, to find the library. And, there's then a tool which lets you modify you library to change its built-in install location, without re-compiling.) So that least there's precedent.
#3, I should point out, will *only* be used on those platforms that don't have a better scheme, and only by the Parrot_get_base_library_path() function.
System registry on Windows? /etc file on Unixen?
Actually, one thing I'd like to see is if it wasn't the library's base
path hardcoded in, but the base path of a frozen data structure or
program that encoded Parrot's settings. That would allow it to carry
the runtime library path, the paths to ICU's tables, the paths to search
for PMCs, and whatever else we can think of, without a hardcoded limit.
The idea (for me, at least) was to specify a directory, and the config file could be a conventional name relative to that--that lets you locate multiple resources without having do read on the config file in order to find them. And semantically, I think of it not as the executable's path--that just happens to be something that's 1:1 with a particular copy of parrot. And definitely not libparrot's path--embedded cases would have to specify the path explicitly, though they could partially mimic the same scheme.
JEff
