At 8:35 AM -0700 4/15/04, Jeff Clites wrote:On Apr 15, 2004, at 7:24 AM, Dan Sugalski wrote:
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 :)
Makes sense to me to just store the path--keep it simple.
That's what I'm thinking, but I can see wanting to have separate paths for parrot's low-level libraries (basically the things we need for parrot to run in the first place) and higher-level libraries (modules installed off of CPAN and whatnot).
That's true. But as long as we grab the "here's where the executable is", we can (later) build API on top of that if we want. For instance, we could decide that core, low-level resources will be located relative to that path, and one of those resources will undoubtedly be a config file of some sort, and that config file could contain the path(s) to look for higher-level stuff. As long as we've "rescued" and stored our location, we've sort of bootstrapped that process.
(And to loop back a bit, the nice thing about bootstrapping this stuff based on our executable's location is that it makes it a no-brainer to have multiple, relocatable installs of parrot. And people would even be able to have 10 different versions of parrot sitting around, but have them all configured to share the same high-level resources.)
JEff
