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".
If I've stuck Parrot in /usr/bin it seems unlikely that I'll have parrot's library files hanging off of /usr/bin.
Right, so you do what Mac OS X does with the java executable--you put a symlink in /usr/bin, pointing to the real location. And your "path to the executable" has to call realpath() or the equivalent to resolve such symlinks (which you need to do in order for path logic to do-the-right-thing).
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. :)
I'm not sure I get your meaning here. By "executable", I mean standalone-parrot, not libparrot, of course. If you mean that libparrot might end up in 100 different places, then you'll not end up with the dynamic linker finding things properly, so you'll have a bigger problem to solve. If you mean that standalone-parrot could end up in 100 different places, then you're going to have 100 different ways you need to set up $PATH just to launch it, but once it's executing you'd still be fine. Or each host will have its own separate symlink in /usr/bin to the right location for that host, and everything will just be fine.
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.
With chroot, frankly, you have the same problem with DLLs, and you end up needing to have all of your necessary external resources located in your chroot-dir so that their paths after the chroot match their paths before. So that was a bad example on my part, really. (And, if you are chroot-ing from within a parrot script, you're in a place where you'd want to re-point your config dir path to match.)
But with interpreter files we could have the problem that the kernel hides the info from us. But for bytecode files, if they're launched like java apps are launched, with "parrot foo", then that problem wouldn't come up.
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)
Yeah, I don't think there's a 100% solution, but it would be nice to have something which works 95% of the time and is flexible/convenient, in preference to something that works 96% of the time and is less powerful.
I think a reasonable approach would be:
1) Always allow the config location to be overridden via a command-line parameter, and change-able from bytecode. (That let's you be 100% unambiguous, at the cost of needing to execute parrot in a particular way. And it's convenient for testing against a whole bunch of different sets of configs without rebuilding.)
2a) On platforms which support it, auto-find the executable, and base the config path on that.
2b) On platforms which don't support that (and even, as a compile-time option for those which support it), have a compiled-in path to use.
This basically matches the API you mentioned before, and boils down to what gets passed to Parrot_set_library_base() (or, call it Parrot_set_configuration_base maybe) at launch time--it gets passed either an explicitly supplied value, an inferred value, or a compiled-in value).
JEff
