1) We add a Parrot_set_library_base(char *lib_path, int length) function to set the base library path
2) We add a Parrot_get_base_library_path() function to the platform-specific interface so platforms can return the base path
Works for me...
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.
#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.
Sound sane? I can see splitting up the library base path into sections, but I'm not sure it's worth it. Now'd be the time to argue that, though :)
-- Brent "Dax" Royal-Gordon <[EMAIL PROTECTED]> Perl and Parrot hacker
Oceania has always been at war with Eastasia.
