IvorW wrote:
Steven wrote:
Because of this, we decided that we couldn't (learn how to)
install PAR on the
customers machine to run our custom scripts, instead we just
installed the large
collection of required modules one by one from CPAN (easier,
because in this
case they were all pure perl).
???
I might have missed the point, but why would you need PAR
> on the customer's machine? The idea is that you have
> PAR installed on your build machine, complete with C
> compiler and everything else - matching the architecture
> and OS version of the customer's machine.
Then, build your maintenance and CGI scripts into
> executables with pp and ship them. There are also tricks
> for building multiple scripts into a single executable,
> symlinking on the target machine.
Okay so they're larger than the original tiny scripts, but
> bandwidth and disk space aren't an issue these days. And
> it'll bypass the pain of installing modules on the
> customer's machine.
Possibly, Steven is referring to the use case where you put your
dependencies in a .par file and use it as a library? Packaging a whole,
complicated application into a binary executable can be daunting. But
bundling CPAN dependencies in a .par is *usually* simple if it does not
involve extra .so's/.dll's.
Anyhow, a scenario that illustrates the benefit of having PAR.pm pure
Perl is where you have an application which can be extended with
plugins. A plugins could, for example, as a .par file with the necessary
classes, extra dependencies, and meta information embedded.
I didn't make this up, though. It's Dan Sully's (of SlimDevices) idea
for their great slimserver app.
Steffen
