> -----Original Message----- > From: Steven Mackenzie [mailto:[EMAIL PROTECTED] > Sent: 29 November 2006 12:02 > To: [email protected] > Subject: Re: RFC: Splitting PAR > > > * Replies will be sent through Spamex to [EMAIL PROTECTED] > * For additional info click -> http://www.spamex.com/i/?v=12245283 > > * Replies will be sent through Spamex to [EMAIL PROTECTED] > * For additional info click -> http://www.spamex.com/i/?v=9636170 > > Steffen Mueller wrote: > > for quite some time now, I have been dissatisfied by that PAR is (at > > least) two things at once which is frequently not > understood by those > > investigating PAR for one or the other things: > > > > a) A Perl packager > > ==> To standalone executables > > ==> To .par archives > > b) A module to use .par archives as libraries (hence the JAR <=> PAR > > analogy) > ... > > Any thoughts? > > A scenario that one of my colleages had is this, which I hope > is accurate from > memory: > > We develop an application that runs on Solaris and Windows, > which uses several > supporting Perl maintenance and CGI scripts. > > One of our customers has a live server on Solaris, and we had > developed several > custom scripts for them, but the typical module dependency > hell problem had > crept in, and we weren't sure exactly what extra modules > needed to be moved to > the live server. > > The customers server allows us to use CPAN to install > modules, but the compiler > configuration is broken in an interesting way. Apparently > CPAN will always try > to use the compiler that Perl was built with, even if that is > not the available > compiler on the live machine (as in our case). > > This makes installing binary modules on our customers server > very tedious > because we need to tweak the configuration of each module by > hand to get it to > install outside of the CPAN shell. > > 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.
