develooper Front page | perl.par | Postings from June 2008

Re: problem with POSIX package and par

Thread Previous | Thread Next
Steffen Mueller
June 1, 2008 01:37
Re: problem with POSIX package and par
Message ID:
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 
- 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/, a glib/, and a bork/ 
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/((?:[^/]+/)*[^/]$| 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).


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About