NAME

Wx::Perl::Packager

VERSION

Version 0.27

SYNOPSIS

For PerlApp/PDK and PAR

At the start of your script ...

#!/usr/bin/perl
use Wx::Perl::Packager;
use Wx;
.....

or if you use threads with your application
#!/usr/bin/perl
use threads;
use threads::shared;
use Wx::Perl::Packager;
use Wx;

Description

Assist packaging wxPerl applications on Linux (GTK)  and MSWin

Wx::Perl::Packager must be loaded before any part of Wx so should appear at the
top of your main script. If you load any part of Wx in a BEGIN block, then you
must load Wx::Perl::Packager before it in your first BEGIN block. This may cause
you problems if you use threads within your Wx application. The threads
documentation advises against loading threads in a BEGIN block - so don't do it.

For PerlApp on MS Windows

putting Wx::Perl:Packager at the top of your script as described above may be
all that is required for recent versions of PerlApp. However, using an x64
64 bit version on PerlApp and 64 bit Wx PPMs, you may encounter a fault on exit
when closing the application. This will be apparant when testing the app. You can
work around this by binding the Wx.dll file as wxmain.dll. That is:

bind somepath..../auto/Wx/Wx.dll
  as
wxmain.dll

This will fix this issue.

Note that PerlApp 8.0 and greater may report incorrect msvcrtXX.dll dependencies
for the wxWidgets dll's. These errors can be ignored. The libraries link only
against the known msvcrt.dll and require no additional MSVCRTXX runtimes.

Windows 2000

Your distributed applications can run on Windows 2000, but you will have to include
the redistributable gdiplus.dll from Microsoft. Search MSDN for
'gdiplus redistributable'.
Once downloaded and extracted, you can simply bind the gdiplus.dll to your
PerlApp executable.

For PerlApp on Linux

if you are using the PPMs from http://www.wxperl.co.uk/repository ( add this
to your repository list), packaging with PerlApp is possible.

You must add each wxWidgets dll that you use as a bound file.
e.g. <perlpath>/site/lib/Alien../wxbase28u_somename.so.0
should be bound simply as 'wxbase28u_somename.so.0' and should be
set to extract automatically.

YOU MUST also bind <perlpath>/site/lib/auto/Wx/Wx.so as
'wxmain.so' alongside your wxwidgets modules. This is the current work around
for a segmentation fault when PerlApp exits. Hopefully there will be
a better solution soon.  

For PerlApp on MacOSX

The Wx distribution available as a PPM from http://www.wxperl.co.uk/repository ( add this
to your repository list), can be packaged using PerlApp and Perl510

For PerlApp packaging and testing, you must set the DYLD_LIBRARY_PATH to the wxWidgets
dylib files before running PerlApp. If you have installed PPMS and the PDK in default
locations, the two required commands will look like:

export DYLD_LIBRARY_PATH=/Users/yourusername/Library/ActivePerl-5.10/lib/auto/Wx/wxPerl.app/Contents/Frameworks
/usr/bin/open "/Applications/ActiveState Perl Dev Kit/PerlApp.app"

Creating and testing the app will work because you have set the DYLD_LIBRARY_PATH environment variable.

Once you have finished working in PerlApp, you will have to make some additions to your created .app .

If your new app is located at mydir/myapp.app, the necessary procedure is

cd mydir.app/Contents
mkdir Frameworks
cp -p /Users/yourusername/Library/ActivePerl-5.10/lib/auto/Wx/wxPerl.app/Contents/Frameworks/* Frameworks

and that should be it. Your app should now be distributable and run without the need for a DYLD_LIBRARY_PATH

This works because the Wx .bundle files and wxWidgets dylib files in the PPM distribution are built to find
dependencies relative to the executable that loads them. If you already have a different packaging method that
relies on setting DYLD_LIBRARY_PATH at run time, then that too should work without problems.

When run on some MacOSX version / architecture combinations (behaviour has been noted on a MacOSX 10.4 G4 ppc machine)
your PerlApp application may cause error dialogs on exit ("Application Quit Unexpectedly")

You can fix this by binding the Wx.bundle file as wxmain.bundle. That is, bind
pathtoyourppminstall/site/lib/auto/Wx/Wx.bundle
   as
wxmain.bundle

You may wish to apply this fix to all your .app packages.

PerlApp General

Wx::Perl::Packager does not support the --dyndll option for PerlApp.

Wx::Perl::Packager does not support the --clean option for PerlApp

Wx::Perl::Packager works with PerlApp by moving the following bound or included
wxWidgets files to a separate temp directory on MSWin and Linux (and Mac OSX
for wxmain.dylib).

base
core
adv
mingwm10.dll if present for 32 bit executables
libgcc_s_sjlj-1.dll if present for 64 bit executables
gdiplus.dll if needed by OS.
wxmain.(dll|so.0|dylib)

The name of the directory is created using the logged in username, and the full path
of the executable. This ensures that your application gets the correct Wx dlls whilst
also ensuring that only one permanent temp directory is ever created for a unique set
of wxWidgets DLLs

All the wxWidgets dlls,  mingwm10.dll and /or libgcc_s_sjlj-1.dll should be bound as 'dllname.dll'.
(i.e. not in subdirectories)

For PAR

PAR assistant

run 'wxpar' exactly as you would run pp.
    
e.g.  wxpar --gui --icon=myicon.ico -o myprog.exe myscript.pl

At the start of your script ...

#!c:/path/to/perl.exe
use Wx::Perl::Packager;
use Wx;
.....

or if you use threads with your application
#!c:/path/to/perl.exe
use threads;
use threads::shared;
use Wx::Perl::Packager;
use Wx

Wx::Perl::Packager must be loaded before any part of Wx so should appear at the
top of your main script. If you load any part of Wx in a BEGIN block, then you
must load Wx::Perl::Packager before it in your first BEGIN block. This may cause
you problems if you use threads within your Wx application. The threads
documentation advises against loading threads in a BEGIN block - so don't do it.

wxpar will accept a single named argument that allows you to define how the
wxWidgets libraries are named on GTK.
wxpar ordinarily packages the libraries as wxbase28u_somename.so
This will always work if using Wx::Perl::Packager.
However, it maybe that you don't want to use Wx::Perl::Packager, in which case
you need the correct extension.

If you want librararies packaged as wxbase28u_somename.so.0, then pass the first
two arguments to wxpar as

wxpar wxextension .0

If you want wxbase28u_somename.so.0.6.0 , for example

wxpar wxextension .0.6.0

which would mean a full line something like

wxpar wxextension .0.6.0 -o myprog.exe myscript.pl

NOTE: the arguments must be FIRST and will break Wx::Perl::Packager (which should
not be needed in this case).

OF COURSE - the symlinks must actually exist. :-)

Nasty Internals

As Commented in Wx:Perl::Packager::Linux the packager is configured with several
options. Mix and match if you think there's a better way.

$self->set_so_module_suffix(''); # different linux dists symlink the .so libraries differently
                                 # BAH. the loaders in Wx::Perl::Packager will look for
                                 # modules ending in '.so'  - If your modules get packaged
                                 # differently, put the suffix here.
                                 # e.g. if your module when packaged is
                                 # wxlibs_gcc_base.so.0.6.0
                                 # you should $self->set_so_module_suffix('.0.6.0')

$self->set_relocate_pdkcheck(0); # relocate the Wx dlls during PDK Check - never necessary it seems

$self->set_relocate_packaged(1); # relocate the Wx Dlls when running as PerlApp

$self->set_relocate_wx_main(1);  # if set_relocate_packaged is true and we find 'wxmain.so'
                                 # as a bound file, we load it as Wx.so ( which it should be
                                 # if user as bound it). This is the current fix for PerlApp
                                 # segmentation fault on exit in Linux. Makes no difference
                                 # in MSWin

$self->set_unlink_relocated(1);  # delete the extracted files - ensures relocated are loaded

$self->set_loadmode_pdkcheck('packload'); # standard | nullsub | packload  during pdkcheck
                                          # standard uses normal Wx loading
                                          # nullsub - no extensions are loaded
                                          # packload - extensions are loaded by Wx::Perl::Packager

$self->set_loadmode_packaged('packload');# as above, when running as PerlApp

$self->set_loadcore_pdkcheck(1); # use DynaLoader to load wx modules listed by
                                 # get_core_modules method (below)during pdkcheck
                                 
$self->set_loadcore_packaged(1); # as above, when running as PerlApp

$self->set_unload_loaded_core(1);# unload any librefs we loaded
                                 # (uses DynaLoader in an END block )

$self->set_unload_loaded_plugins(1); # unload plugins ( html, stc, gl .. etc) that are
                                     # loaded via 'packload'. This seems to be necessary
                                     # to ensure correct unloading order.
                                     # Note - plugins are loaded using
                                     # Wx::_load_plugin  (not DynaLoader);

$self->set_pdkcheck_exit(1);     # because of the current seg fault on exit in linux
                                 # you can't package using PerlApp
                                 # this setting calls 'exit(0)' after
                                 # Wx has loaded.
                                 # Drastic - but it is the current hack for this failure on linux

Packaging Test Script

There is a test script at Wx/Perl/Packager/resource/packtest.pl that you can
use to test your packaging method. (i.e. package it and check if it runs);

Methods

Wx::Perl::Packager::runtime()

returns PERLAPP, PARLEXE, or PERL to indicate how the script was executed.
(Under PerlApp, pp packaged PAR, or as a Perl script.

my $env = Wx::Perl::Packager::runtime();

Wx::Perl::Packager::packaged()

returns 1 or 0 (for true / false ) to indicate if script is running packaged or as
a Perl script.

my $packaged = Wx::Perl::Packager::packaged();

Wx::Perl::Packager::get_wxpath()

returns the path to the directory where wxWidgets library modules are stored.
Only useful when packaging a script.

my $wxpath = Wx::Perl::Packager::get_wxpath();

Wx::Perl::Packager::get_wxboundfiles()

returns a list of hashrefs where the key value pairs are:

boundfile   =>  the relative name of the file when bound (e.g myfile.dll)
file        =>  the source file on disc
autoextract =>  0/1  should the file be extracted on startup

Only useful when packaging a script. If called within a packaged script,
returns an empty list. In addition to the wxWidgets dlls, this function
will also return the external and required bound location of the
gdiplus.dll if present in Alien::wxWidgets. If bound to the packaged
executable at the required location, Wx::Perl::Packager will ensure that
gdiplus.dll is on the path if your packaged executable is run on an
operating system that requires it.

my %wxlibs = Wx::Perl::Packager::get_wxboundfiles();

Wx::Perl::Packager::get_wxlibraries()

This function is deprecated. Use get_wxboundfiles() instead.

returns a list of the full path names of all wxWidgets library modules.
Only useful when packaging a script. If called within a packaged script,
returns an empty list.

Use Wx::Perl::Packager::get_wxlibraries();
my @wxlibs = Wx::Perl::Packager::get_wxlibraries();

AUTHOR

Mark Dootson, <mdootson at cpan.org>

DOCUMENTATION

You can find documentation for this module with the perldoc command.

perldoc Wx::Perl::Packager

ACKNOWLEDGEMENTS

Mattia Barbon for wxPerl.

COPYRIGHT & LICENSE

Copyright 2006 - 2010 Mark Dootson, all rights reserved.

This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.

cpanm Wx::Perl::Packager

perl -MCPAN -e shell
install Wx::Perl::Packager