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). So I like your suggestion :-) Steven
