Activestate is a for profit company. They can't sell perl but they can
sell support, especially corporate support. Take a look at their
services. It makes a lot of sense for them to have their tools only
work on the distribution they put together if they want to efficiently
support it.
My experience is this not a bad thing. You can still add in any modules
you want via the various install methods - on linux anyway.
On 8/3/2010 1:59 AM, Jan Dubois wrote:
PerlApp supports many platforms (AIX, HP-UX, Linux, Mac OS X, Solaris,
Windows), and generally requires a version of Perl that has been
compiled with the same options as ActivePerl. Therefore the
documentation lists the various minimum versions of ActivePerl that are
supported.
The Perl versions distributed by various vendors (Apple, IBM,
Sun/Oracle, Red Hat) are mostly not compatible with ActivePerl and will
therefore not work with PerlApp.
Strawberry Perl however is compiled with the same options as ActivePerl
and is at the core very similar. The differences are more in the
packaging, and in additional stuff that is included in each
distribution.
I know that the standard regression tests for the PDK did pass with the
latest Strawberry Perl releases, so I'm sure it works in general, but
there are always little details that might be different. If we get a
concrete bug report, then we'll try to fix it, if possible with a
reasonable amount of effort.
One feature of PerlApp 9.x that won't work with Strawberry though is the
cross-platform wrapping: you can use ActivePerl and PerlApp on Windows
to build binaries for Linux and OS X. This requires that the local Perl
installation includes PPM4, which is only available in ActivePerl.
One thing is not quite clear to me though: Once you build a standalone
executable with PerlApp you no longer need ActivePerl or Strawberry Perl
on the deployment system (that is kind of the point of the whole exercise),
so why does it matter if you build with one vs. the other?
Cheers,
-Jan
On Mon, 02 Aug 2010, Octavian Rasnita wrote:
I haven't tried perlapp with Strawberry Perl, but if I remember well I read
somewhere that PDK only works with ActivePerl. Maybe the announcement made
by ActiveState wasn't clear.
It was something like "PDK version X only works with ActivePerl version X
and above". Maybe it should have been "works with Perl X and above".... but
I am not so sure because I think I also remember that I've read explicitly
that PDK requires ActivePerl.
Isn't this true?
--
Octavian
----- Original Message -----
From: "Jan Dubois"<j...@activestate.com>
To: "'ademmler'"<n...@ademmler.com>; "'Johan Vromans'"
<jvrom...@squirrel.nl>; "'Daniel Carrera'"<dcarr...@gmail.com>
Cc:<wxperl-users@perl.org>
Sent: Tuesday, August 03, 2010 1:12 AM
Subject: RE: AW: Distributing wxPerl applications
On Mon, 02 Aug 2010, ademmler wrote:
hi,
I am using all of those tools and the major difference is the concept
behind:
B) ActiveStae perlapp I could not run wtihout ActiveStae Per . . .
(non strawberry)
Could you provide me with a sample that fails? PerlApp generally works
fine with Strawberry Perl, but I haven't tested it with Strawberry and
wxPerl.
Ideally I would like to know:
* Exact version of Strawberry Perl
* How you built/installed wxPerl (and which version)
* Version of the PDK (`perlapp --version --verbose` output)
* Small sample script
* Did you use Wx::Perl::Packager (which version)
* Commandline used to wrap the sample script
* How it fails to work (any error messages?)
Cheers,
-Jan
__________ Information from ESET NOD32 Antivirus, version of virus
signature database 5335 (20100802) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
__________ Information from ESET NOD32 Antivirus, version of virus signature
database 5335 (20100802) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
