Octavian,
I have a solution to distributing the wxWidgets DLLs separately which takes the
form of a PDK shared executable.
It can be downloaded from
http://www.wxperl.co.uk/pdk_wx_runtime.zip
This zip should be extracted preserving folders.
At the top level it includes a README.txt file that is attached here also and
explains all.
You need PDK 7.2 to use it.
In brief, all the main Wx modules are packaged in the shared executable which
has been created in such a way that it expects to find the wxWidgets DLLs in
your --runlib directory.
So there are no temporary directories or cleanup problems as far as the
wxWidgets DLLs are concerned.
--dyndll still does not work reliably. To do that would require loading
auto/Wx/Wx.dll out of the --run lib dll too. This is possible but I have not
done it as it is one ugly hack too far.
How did I create the shared executable?
Create a perl script that just consists of 'use Wx::nnnn;' statements for all
the Wx modules.
Create an altered Wx::Perl::Packager that knows wxWidgets DLLs are in the
runlib.
Temporarily rename your Alien/wxWidgets directory (so that perlapp can't find
the wxWidgets DLLs)
Package this wx script with PerlApp using the altered Wx::Perl::Packager too.
Fix the path to Alien/wxWidgets again.
Remove the altered Wx::Perl::Packager from your @INC, restoring the CPAN
version.
That's it.
Hope it is useful.
Regards, Mark
Octavian Rasnita wrote:
Ok, I can specify the location of the dll files on the target machine,
but I don't know how to prevent that they are included in the executable.
I've also seen that the following is included by wxpdk in the .perlapp
file and I don't know what it is used for:
Bind:
gdilib/gdiplus.dll[file=E:/usr/site/lib/Alien/wxWidgets/msw_2_8_7_uni_mslu_gcc_3_4/os/gdiplus.dl_,mode=444]
Strange, but I've tried to create the executable without
Wx::Perl::Packager, using:
perlapp --gui program_name.pl
and it created an executable that works fine.
So I still don't know how I succeeded to build a .exe program without
Wx::Perl::Packager nor how to avoid including some dlls.
Octavian
From: "bungsuputra linan" <[EMAIL PROTECTED]>
Yes, I think it's possible. In PerlApp window, go to "Options 1" tab and
under "Run Library", you can specify the location of dll files in "Use
run library".
I hope it helps.
Regards,
bungsu
On Fri, 2008-03-21 at 13:48 +0200, Octavian Rasnita wrote:
Hi,
Is it possible to exclude the dll files which are needed by WxPerl to
run in
a PDK - generated executable?
(And put them separately in the same dir with the executable)
Thanks.
Octavian
==============================================
Distributable Wx for PDK
==============================================
-----------------
License.
-----------------
The modules and binary objects (libraries) contained in this
package are subject to their own licences and conditions
concerning use and redistribution. This package ASSISTS you
in distributing Wx Perl modules and associated wxWidgets
libraries that you have independently installed on your system.
YOU are subject to the individual license terms of each module
and library if you choose to distribute those modules and libraries.
----------------
Usage.
----------------
This package provides two shared executables for the ActiveState
PDK that allow you to distribute applications using Wx.
In the runlib directory you will find:
libwx_720_822_082_287.dll
libwx_720_1002_082_287.dll
These dlls are actually PDK packed executables that you can use
as shared executables when packaging and distributing your Wx
applications.
The dll names contain 4 numbers which are, in order:
The version of the PDK used to pack the dll (720)
The version of ActiveState Perl - 822 is Perl 5.8.8, 1002 is Perl 5.10.0
The CPAN version of Wx
The version of wxWidgets.
The contents of the shared executables are taken from the unicode PPM
repositories at http://www.wxperl.co.uk/repository so you must use
these PPMs for your development.
To use the shared executables, ensure that the first line of your script
is:
use Wx::Perl::Packager;
(or the third line if you are using threads / threads::shared).
Do NOT use the wxpdk utility to create a starting perlapp file.
Add the appropriate shared executable file to your PerlApp options.
In the GUI add the appropriate file as a 'shared executable' to the
top of your 'Module Search Path' on the main tab.
The commandline option if using ActivePerl 822 would be:
--use ../pathtodlls/libwx_720_822_082_287.dll
This will mean that PerlApp will not attempt to package any of the main
Wx modules. (as they are in the shared dll).
You must also, of course, specify a 'runlib' for your application. I
normally install my executables in a directory called 'bin' and have
alongside it at the same level a directory called 'lib'. This means I
can specify a relative runlib as '../lib'.
When you distribute your application, you must distribute the shared
dll you have referenced along with all of the wx dlls in the runlib
directory of this zipfile and mingwm10.dll. These should all be
placed in your --runlib directory.
You only have to distribute the particular libwx_720_nnnn_082_287.dll
that you have referenced for your version of Perl.
----------------
--dyndll option
----------------
This does not work reliably with Wx and no attempt has been made to
support it in preparing this package.
------------------------
Windows 2000, Me, 98, 95
------------------------
In the runlib directory of this zip, you will find two subdirectories
W2K and W98. Each contains a text file.
If you intend to redistribute your application to Windows 2000 machines
or below, you need to distribute the gdiplus.dll. See the text file in
the W2K subdirectory for further information.
If you intend to redistribute your application to Windows Me machines
or below, you need to distribute the unicows.dll. See the text file in
the W98 subdirectory for further information.
As this is a package clearly intended for redistribution, I cannot
incorporate gdiplus.dll or unicows.dll due to their respective licences.
As a provider of an application to an 'end user', you may well feel that
you can distribute either or both of these dlls directly with your
application. You will have to decide.
You can always take the same option as I have and direct users on older
operating systems to Microsoft.
