use Perl

• Packaging, not compiling (Score:1)

  by jplindstrom (594) on 2007.10.24 8:48 (#58553) Journal

  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.

  Reply to This

  • Re: (Score:1)

    by tsee (4409)

    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 par.perl.org? 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
    • Re: (Score:1)

      by jplindstrom (594)

      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.