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
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Packaging, not compiling (Score:1)
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.
Re:Packaging, not compiling (Score:1)
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 possible. In those cases, you can just add a sub that is never called to some package which will be scanned. In that subroutine, you would then put "require Foo;" for every module the packager doesn't find by itself. The require will never be executed, but it will be recognized as a dependency by the packager.
By the way: I entirely agree with you that it's questionably whether Perl is a legitimate choice in this case. There is Steve Hay's Filter::Crypto (and PAR::Filter::Crypto) which is intended to make it harder to get at the code. It goes as far as possible with perl. Make sure you read the CAVEATS section thoroughly before use, though.
Reply to This
Parent
Re: (Score:1)