> Yes, you'll need to manually add the 256 submodules right now.  I'll add
> a heuristic to PDK 7.2 to detect this automatically and include all of
> them.  Should be released in a couple of weeks.
>
> Cheers,
> -Jan
>
> On Mon, 17 Mar 2008, Thurn, Martin wrote:
>   
>> Text::Unidecode does run-time 'require' of modules. There's no way for
>> perlapp to know at compile time what modules will be needed at
>> runtime, of course. You'll have to add explicit 'use
>> Text::Unidecode::x01' (or perlapp --add) for every bank you think
>> you'll need. (No, I don't know what a bank is, I just glanced at the
>> Unidecode.pm source code)
>>
>>     
> On Sat, 15 Mar 2008, Octavian Rasnita wrote:
>   
>> ...Am I doing something wrong? Can I do something to make it work? Or
>> PDK doesn't work with Text::Unidecode?
>>     
Just as an aside, I typically achieve this with 'require' rather than 
'use' or '--add' for modules that have this issue.

I try to make my projects run either 'normally' or as perlapped stuff. 
Having tons of --add makes the compile line messy, and I have to 
maintain it 'away' from the code. Also, using 'use SomeModule' causes 
the module to be evaluated when I run with plain Perl.

So instead I have 'require SomeModule if 0;' where pertinent, which 1) 
keeps the knowledge 'close' to where I use the actual module that 
dynamically use it, 2) avoid a messy compile line, and 3) won't be run 
in a regular Perl execution but *does* cause PerlApp to pick up on it 
for the only purpose of including it.

So far, this works nicely for me...YMMV of course :-).

(Also, I'd be interested to hear if anyone can see a problem with that 
approach...!)

ken1
_______________________________________________
ActivePerl mailing list
[email protected]
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Reply via email to