On Apr 15, 2004, at 9:36 AM, Dan Sugalski wrote:
At 8:54 AM -0700 4/15/04, Jeff Clites wrote:On Apr 15, 2004, at 8:41 AM, Dan Sugalski wrote:
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.
Well, yeah, but... where the executable is ought, honestly, to be irrelevant.
Yes, in a sense it's irrelevant, but it's the only thing that's 1:1 with a particular "copy" of parrot. It's the only thing (that I can think of) which continues to work if you move your distro around, and which naturally avoids problems with having multiple copies, and lets things work even if you don't "install".
At this point I can say I don't honestly care all that much, and most of my worries are based on vague feelings that there are platforms out there where finding the actual executable name is somewhere between hard and impossible. I will, then, do the sensible thing and just punt on this--we can work out a best practices thing and enshrine it as the default on systems which can support it and be done with it.
The other question, then, is do we see the need for multiple categories of library which would want separately settable library paths? (Don't, here, forget the potential needs of embedders such as Apache) Once we get that thumped out I'll make the API additions.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
