Re^2: pp - where is the Perl interpreter ?

I thought about wrapping the sons as pp packages, but it looks silly - the difference between fathers and sons is their bytecode, so why to replicate the whole thing, including the interpreter ?

I understand that an interpreter instance has to be invoked per father/son, but why to replicate all the binary files belonging to interpreter ?

Comment on Re^2: pp - where is the Perl interpreter ?

Replies are listed 'Best First'.
Re^3: pp - where is the Perl interpreter ? by mr_mischief (Monsignor) on May 14, 2009 at 19:21 UTC
That's simply the way the tool works. There's actually a decent argument if you're going to be packaging multiple programs as part of one application (or application suite/group) not to use pp to do so, to avoid that replication. It may take some more fiddling and be less convenient for you as the developer, but since any recent perl should be relocatable on disk you can actually provide one single perl in your project's installation directory. You can then have all the programs use that. You can then package with parl rather than pp or not package the programs up at all. You'd just have your installation program extract the whole thing and set up any shortcuts or menu items.	[reply]

Replies are listed 'Best First'.

Re^3: pp - where is the Perl interpreter ?
by mr_mischief (Monsignor) on May 14, 2009 at 19:21 UTC

It may take some more fiddling and be less convenient for you as the developer, but since any recent perl should be relocatable on disk you can actually provide one single perl in your project's installation directory. You can then have all the programs use that. You can then package with parl rather than pp or not package the programs up at all. You'd just have your installation program extract the whole thing and set up any shortcuts or menu items.

[reply]