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. If I've stuck Parrot in /usr/bin it seems unlikely that I'll have parrot's library files hanging off of /usr/bin. And if I've got a few hundred machines with parrot's library NFS mounted in different places (to match conflicting vendor standards and other whackjob breakage which is endemic in, well, the world) it really falls down. :) Add to that you can't always figure out where Parrot really is both because of chroot behaviour and some odd "where am I really" problems with suid scripts in some places.
There are a couple of folks who could make your brain melt and flow out your ears with all this stuff too.
Having the executable path as an optional way to get the info's not necessarily a bad thing, but I think it's safe to say that it's not The Right Thing. (If there even is one)
If nothing else this has convinced me we need a way to specify site policy at build time for all this nonsense^Wfun. :)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
