TT (Tangentially Topical): it would be nice if Parrot could avoid as many hardcoded paths as possible for configs, libraries, and such, so that the Parrot installation could be relocated as freely as possible.
Well, then...
Given that everyone's weighing in on this one, it seems worthy of sane consideration. (I keep not thinking about this, as I'm used to the nicely sane VMS logical system :)
As we've got the unpleasant issues of OSes with Really Lame schemes, and embedders that may want to use alternate resource locations, it seems like the right thing to do here is to make this a part of the embedding interface and have the main parrot wrapper set it.
So, I'm thinking a few things:
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
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.
#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.
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 :)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
