Re: [wxperl-users] Modifications for PAR/PerlApp by Mark Dootson

[Mark D. <mar...@zn...>]

Jan / Mattia

Obviously, you two will have to decide which is your preferred way to go 
on this.

My take on it is that having Wx::Perl::Packager::PDK as a separate thing 
means you are more easily able to cope with different release cycles of 
  wxPerl, wxWidgets and PerlApp. Also, it means it is one small aspect 
of wxPerl that Mattia can forget about.

But I guess it would be straightforward to incorporate directly in 
PerlApp. As long as wxWidgets loads DLLs on Win32, and Mattia allows the 
load_dll / unload_dll functions to be overridden, any amendments to 
PerlApp should continue to work, I think.

If there is anything I can do to help, let me know.

Regards

Mark

Jan Dubois wrote:
> Hi there,
> 
> Sorry for coming a bit late to this discussion!
> 
> I think it would be preferable if PAR/PerlApp/perl2exe etc. would deal
> with wxPerl correctly automatically and not require the user to install
> and load any additional modules.
> 
> PerlApp for example already has some heuristics for wxPerl built in.
> E.g. it understands Wx::wx_boot() to be something like the Dynaloader
> bootstrap() function and uses it to determine additional dependencies.
> 
> Therefore I think that maybe the functionality of the PerlApp wx packager
> should be built into PerlApp as well.  I'm sure somebody else would/could
> do the same for PAR etc.  The important thing for this to work in the
> long run is that this mechanism needs to remain stable for future
> releases of wxPerl.
> 
> So please let me know if you think this is a feasible approach, and if
> you would want to look into this with me!
> 
> Cheers,
> -Jan (ActivePerl and PDK tech lead at ActiveState)
> 
> 
> On Thu, 12 Jan 2006, Mark Dootson wrote:
> 
>>Mattia,
>>
>>Version built from CVS now works fine for me with both PAR and PDK/PerlApp.
>>
>>(Tested ActivePerl 5.8.7 815, PAR 0.90, PDK 6.0.2, wxWidgets 2.6.2 VC6
>>build)
>>
>>I'll see if I can get my first efforts at the PDK / PAR specific modules
>>packaged properly for CPAN.
>>
>>Have you any preference for the namespace for this? Or should I just
>>keep Wx::Perl::Packager etc. ?
>>
>>Regards
>>
>>Mark
>>
>>Mattia Barbon <mat...@li...> wrote:
>>
>>>  Hello,
>>>
>>>
>>>
>>>>I think you will have to retain a working load_dll?
>>>
>>>
>>>  I committed a modified version of your changes: you are now able
>>>to override load_dll and to install a shutdown routine that will be run
>>>in an END block. I did not add a 'use Wx::Perl::Packager' statement
>>>to Wx.pm because it seemed not necessary (no function from W::P::P
>>>was used in the default load/unload routines). let me know if
>>>anything is missing.
>>>
>>>
>>>
>>>>F.Y.I.,  in the PDK/PerlApp there are a three issues to cope with.
>>>>
>>>>1. At packaging time, the PDK plays nicely provided NO Wx dlls get
>>>>explicitly loaded so the $ENV/noop change works for this.
>>>
>>>
>>>  Ok.
>>>
>>>
>>>
>>>>2. At run time - same problems as PAR with HTML parsed output.
>>>
>>>
>>>  I forgot to check about this. Hmm.
>>>
>>>
>>>
>>>>3. If load_dll is left working, when a packaged PDK app is run, it will
>>>>seg fault on exit unless any loaded WxDLLs are explicitly unloaded using
>>>>wxPluginManager::UnloadLibrary. For reasons which I don't fully
>>>>understand, the temp copies of wx dlls are still 'loaded' during PDK
>>>>cleanup, and it can't delete its temporary directory. Explicitly
>>>>unloading the DLLs solves this.
>>>
>>>
>>>  Because for every explicit load_dll(LoadLibrary) there must be an explicit call to UnloadLibrary
>>
>>to unload the DLL for the DLL to be
>>
>>>really unloaded hence not in use anymore and hence deleteable by Windows. Changing PATH and thus
>>
>>not making explicit calls to load_dll/LoadLibrary
>>
>>>would solve this problem, but apparently cause 2). I will investigate.
>>>
>>>Regards
>>>Mattia
> 
> 
>