Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • I've used both PAR/pp and PerlApp for a long time. They both do the job very well. Sometimes they have problems with an app and I didn't bother to trouble shoot it but rather just switched to the other one and it worked. That's rare though.

    Using PAR + Inline::CPP has been a bit of trouble, but even that could be worked around.

    Both suffer from the dynamic problem that not all modules can be inferred from a static inspection of the code, but it's nothing hard to work through if you're aware of the situation. Just "use" each missing module manually. (Silenced failures to use modules are really annoying though.)

    But none of this matters if you want to follow the spirit of "it must be compiled", because these aren't _compilers_ in the traditional sense, they _package_ the Perl source in an auto-extracting .exe file and extracts it before the first execution.

    So given the requirements, clearly Perl isn't a legitimately choise.
    • If you figured out the issues with using Inline::CPP with PAR, would you be so kind as to write up a FAQ entry for the FAQ at I would think you might not be the last person to have trouble with that.

      As for adding "use Foo;" for every module so that the packagers can pick it up: That may be undesirable in several occasions. For example, you may have optionally loaded modules, environment/OS dependent modules, or just the case where you want a GUI app to show a loading-progress-bar as soon as po
      • Come to think of it, regarding making sure modules get picked up, there are command line options to add modules as well. I just thought it was easier to put them in the source.