call me a cynic, but par is never that easy. i find i have to say a prayer first, throw salt over my shoulder, and avoid full moons when using it ... and then, if i am lucky, par works 3 out of 4 times. i find old par .exes which used to run stop doing so. par programs which used to compile on one xp box don't on another. i know i sound like complainer, which isn't my intent. par is great, the concept is great, the fact the bundling works is an amazing technical feat, the fact the bundle is a zip file which can be dissected is damn cool too. i like par. i try to use par. most of time i can use it successfully. but par is, by its nature, much less reliable than typical of most perl technologies (which almost never hiccup). not a complaint, not a rant, just my opinion.
Re^4: Win32 development
Replies are listed 'Best First'.
I have found that par is highly sensitive to the surrounding perl install. I use it on my machine all the time, and the executeables work flawlessly on any machine they're deployed on. However, I have a coworker and executeables created by par on his machine are a downright nightmare. Only maybe 1 in 5 works on any other machine at all, and often the generated executeables require perl56.dll. This is especially odd since the executeables produced on my machine tend to be significantly smaller (10% or so) than the ones produced on his, for the same script.
Now, in theory we're both using the same version of ActiveState's perl, and the same version of PAR. However, his is installed in some personal subdirectory (something like C:\Stuff\Perl), and I think there might be some weird permissions issues with it too. Mine was installed, from a clean system, straight into C:\Perl.
indeed, my perl on the winbox in question is c:\perl, which i think is nonstandard. good to know -- par is so worthwhile i'll happily deinstall perl and reinstall in default location.... thanks for the tip!