Hi Glenn, hi all,
Glenn Linderman schrieb:
Now if a library was not originally part of the <perl-install> tree, it
is an open question where it should be installed... and maybe that is
what you are referring to?
Unless I'm grossly mistaken, that's exactly what Scott is referring to.
So then in the PAR case we have
<par-cache-for-this-app>/(lib|bin|script) and you are suggesting that
anything that is included from other parts of the original file system
should be placed in <par-cache-for-this-app>? I'd have suggested
placing them in <par-cache-for-this-app>/script -- the script and any
non-perl stuff should go there?
I don't see any reason to put non-perl stuff in script, to be honest.
Maybe this is a Windows thing where people generally put dlls next to
the executables in PATH?
My suggestion would be the following:
- For any Perl stuff, use the original paths and names.
- For shared libraries added with -l, use shlib/ORIGINALNAME or whatever
that path's called. Add that to LD_LIBRARY_PATH and -- on Windows -- to
PATH.
- For data files added with -a, use the main cache directory and the
original file name.
Now, what happens if filenames of external shared objects clash? There
might be a sys/libfoo.so, a glib/libfoo.so, and a bork/libfoo.so
required by the same program, as far as I know. (Is that right?)
We can't possibly recover those paths by looking at them unless we test
against something like m|\blib/((?:[^/]+/)*[^/]+.so)$| on Linux and use
$1 for extraction. But that's not going to work. And I digress...
So maybe -l should accept syntax similar to -a, except it places things
under /shlib instead of / (i.e. -l/usr/lib/sys/foo;sys/foo).
Cheers,
Steffen
