Re: Active perl Perlapp problem

Sometimes when you have something like this:

use DateTime::Format::ISO8601;
use DateTime::Format::Strptime;
[download]

You need these statements before that also:

use DateTime;
use DateTime::Format; #maybe even this also
[download]

I prefer to add use statements to the source code rather than adding options to the perlapp command.

Update: BTW I prefer the PerlApp GUI instead of the command line. Type "perlapp" with no parameters to start it.

Comment on Re: Active perl Perlapp problem Select or Download Code

Replies are listed 'Best First'.
Re^2: Active perl Perlapp problem by Anonymous Monk on Aug 22, 2018 at 08:59 UTC
Have you tried DateTime::**?	[reply]
Re^3: Active perl Perlapp problem by Marshall (Canon) on Aug 23, 2018 at 18:36 UTC
I guess you are the same anon Monk who wrote: perlapp --add DateTime::** ... foo.pl No I didn't test that. However, it looks like it would work. As I explained, I prefer to modify the source code so that this "--add" option is unnecessary. This has the benefit of eliminating one extra piece of info to keep track of! After the usual activity around the first release, some of my apps can run for 4-5 years before I get a bug report or feature request. A lot can change over the years (Perl version, PerlApp version, other dev environment things, predominate user platform, etc). If I have to revisit a piece of code, I will rebuild the .exe using the latest Perl and Perlapp versions and of course use my QA testing process. If perlapp just runs without requiring any special options, so much the better for me. BTW, I don't use the Perlapp command line anymore. Run the GUI by just hitting CR after PerlApp. At the end of day, there is more than one way to solve this problem. I have good reasons based upon 20 years of experience for why I do what I do. However this doesn't have to be a "one size fits all" situation.	[reply]


Pathologically Eclectic Rubbish Lister
	PerlMonks