The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.

NAME

Wx::Perl::Packager

VERSION

Version 0.18

SYNOPSIS

    Assist packaging wxPerl applications on Linux (GTK)  and MSWin
    
    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;

TEST

    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);
    

DESCRIPTION

    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 should be
    all that is required for recent versions of PerlApp.

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
    should be bound simply as 'wxbase28u_somename.so' 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.  
    

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:
    
    base
    core
    adv
    mingwm10.dll if present
    gdiplus.dll if needed by OS.
    wxmain.so (required on linux)
    
    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 and mingwm10.dll should be bound as 'dllname.dll'.
    (i.e. not in subdirectories)
    
    The wxpdk utility takes care of this for you for PDK versions less than 8.x
    For PDK versions 8 and above, wxpdk should not be used.

For PAR

    run 'wxpar' exactly as you would run pp.
    
    e.g.  wxpar --gui --icon=myicon.ico -o myprog.exe myscript.pl
    
    Also provided are:
    
    wxpdk (PerlApp version 7.x and below )
    wxpar
    
    which assist in packaging the wxWidgets DLLs.

Nasty Internals

    see comments in Wx:Perl::Packager::Linux

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.

2 POD Errors

The following errors were encountered while parsing the POD:

Around line 231:

'=item' outside of any '=over'

Around line 282:

You forgot a '=back' before '=head1'