For my job I need to do the same few repetitive actions on about 35 Windows PCs. It's a kind of work that's quite tricky to do using the normal Windows GUI, but that is quite easy to script in Perl. There's still one problem: none of all these PCs has Perl, and I'm not going to install it for a simple, one time task.
I found it works pretty well, though there are a few warts:
$0has the value "-e", which makes it impossible for the script to find out its own directory, as I haven't found any other way to find that out
globmakes it crash. I suspect there's an incompatibility between the DLL of
tinyperl.exe, because it crashes also when you just use
tinyperl.exeinstead of plain
perl.exe, and not just when running the packed script.
At least, PAR decompresses its archive (that is embedded in the executable itself instead of in a separate file) in a directory for temporary files. (Why do these files need to be decompressed to a file anyway? Why can't they be loaded from RAM instead?)
Well that shatters any hope of getting any bugs fixed, at least, in a timely manner...
But somewhere on this project's homepage was a link to another, related Sourceforge project: PerlBin, from the formerly very active crazyinsomniac AKA PodMaster, who also vanished from the face of this earth...
I find it quite impressive. The project is only a Perl module, with a package of just 16k... and a script, called
perltobin. You can allegedly use it for a vast array of platforms, provided you have a C compiler... or you can use the "binary" package for ActivePerl on Windows, either 5.6.x or 5.8.x, which doesn't require a C compiler at all the pre-compiled to-be-linked-in library is included in the distribution.
It has a different set of properties, from the same (limited) point of view (for this project):
globworks, though you need to explicitely invoke
File::Globto include the necessary files that appears to be caused because Module::Dependency doesn't seem to catch it by default.
$0is set to the path of the executable file, so it can deduce its own file path
BTW it appears to be built upon GMPassos' work, but with a different focus, apparently.
And then, there is PAR. I haven't tried it for this project, but even though it has the great advantage of producing just one executable file, it also has the disadvantage of building temp files for the modules when it runs, which makes the behaviour less than professional; just like TinyPerl, but unlike PerlApp/perl2exe (AFAIK). Somehow I always found
PAR quite daunting, so this has always been a bit of a showstopper to me.
But I like having the choice between alternatives, and I can dream of a merged project, with a "best of all worlds", and one that doesn't need any tempfiles, as I'm quite sure that it must be possible. I just don't know how, yet.