Am 30.06.2016 um 11:58 schrieb Johan Vromans:
On Thu, 30 Jun 2016 00:14:00 +0200
Roderich Schupp wrote:
On Wed, Jun 29, 2016 at 11:49 PM, Johan Vromans
wrote:
pp executables are not as stand-alone as the ones from Cava and
PerlApp.
Care to elaborate?
Sure.
I've been working with PerlA
Am 18.09.2014 um 10:25 schrieb RAPPAZ Francois:
If I compare that tmp folder with other archives I made with par, I see that
it’s lib/auto/Clone I have
So I wonder what on earth produce the lower case …
Hi Francois,
did you check for a 'use clone;' in your sources?
Cheers Christoph
Am 07.08.2013 10:51, schrieb Roderich Schupp:
On Wed, Aug 7, 2013 at 9:52 AM, Ch Lamprecht mailto:ch.l.n...@online.de>> wrote:
But most of the referenced dlls are provided by the system and we don't want
to pack these...
Yes, that's the next problem: how to weed out
> What would be required would be a tool to scan the known DLLs for other DLLs
> they reference.
>
>
> Exactly. Unfortunately such a tool is highly platform dependent.
For Windows there is ProcessExplorer - or ListDLLs if you prefer a command line
tool. But most of the referenced dlls are pro
Hahn, Christopher wrote:
Hello,
"No compiler found"
If I were doing this, I would probably run the bat file
that came with my MS C compiler (was it MSDev32.bat?), the
one that sets up paths for compilation, then I would try
the PAR build again.
In any case, you need to make sure that a C com
Steffen Mueller wrote:
thorough testing. It would be great to have some PAR::Packer tests for
the new feature and we definitely need to document it.
Hi,
I just committed 'cachedeps' pod for pp and test for PAR::Packer to trunk.
Cheers, Christoph
Steffen Mueller wrote:
I tested your patch (with slight modifications) and these initial,
rough, tests seem to show everything is okay. The patch comes with no
tests, however. I think we should figure out a way to add at least a few
simple tests.
To make all of this easier, I just created a
Steffen Mueller wrote:
Hi Christoph,
Ch Lamprecht wrote:
if anyone is interested, here is what I am testing at the moment.
Added cache_cb to M::SD as described before and using it from
PAR-Packer. PAR-Packer gets a cd|cachedeps (filename) option.
I use it like 'pp -cd dep
Hello,
if anyone is interested, here is what I am testing at the moment. Added cache_cb
to M::SD as described before and using it from PAR-Packer. PAR-Packer gets a
cd|cachedeps (filename) option.
I use it like 'pp -cd deps.dat -more_options script.pl' or
'pp -cd deps.dat -o test.exe -e "us
Ben Morrow wrote:
Quoth ch.l.n...@online.de (Ch Lamprecht):
there is a bug in Module::ScanDeps which causes {type} to be set to 'data'
instead of 'autoload' in some cases - and changing if the same file is scanned
more than once.
I attach a patch to fix this and a testfile.
Hello,
there is a bug in Module::ScanDeps which causes {type} to be set to 'data'
instead of 'autoload' in some cases - and changing if the same file is scanned
more than once.
I attach a patch to fix this and a testfile. With the patch *.bs files are
always reported as 'autoload' - is that co
Steffen Mueller wrote:
No worries. Thanks for diving into the guts of PAR::Packer to implement
the feature! My only criticism is that I somehow feel this would be
better put into Module::ScanDeps which does the actual dependency
checking.
Hello,
in my first attempt I tried to cache the w
Steffen Mueller schrieb:
Hi Christoph,
Ch Lamprecht wrote:
<< Now I was making up my mind about the possibility to add a
dependencies cache - most of the time my dependencies do not change - and
just tried it. It's a quick hack: uses Storable to store/retrieve state
Hello List,
I am maintaining a perl/Tk database app and use PAR::Packer to create binaries.
Works perfect on Linux/ MacOS /Windows - thanks for a great tool.
There are a lot of dependencies in my app therefore the packing takes some
minutes. Now I was making up my mind about the possibility to ad
Mon Jun 22 03:17:49 2009: Request 47209 was acted upon.
Transaction: Correspondence added by ch.l.n...@online.de
Queue: Module-ScanDeps
Subject: Re: [rt.cpan.org #47209] Missing dependencies with Tk::Widget ->
setPalette() (patch)
Broken in: 0.90
Severity: (no value)
Owne
Steffen Mueller schrieb:
To cut that story short: I'd love to get a test case for this which
needs neither Storable nor PAR so we can add the test to core, too.
Hi Steffen,
I didn't find a better example, so I post it here - maybe someone more
knowledgeable wants to give it a try.
I tried to
Steffen Mueller wrote:
Hi,
It looks like some weird interaction between PAR and Autoloader.
The reason for the error message seems to be that auto/Storable/_retrieve.al
is loaded BEFORE auto/Storable/autosplit.ix (so that logcarp isn't known
to be a sub). In fact, I get the same error message
Hi,
trying to pack an application that uses Storable with the --clean switch I got
stuck:
Strawberry-perl 5.8.8
$Storable::VERSION2.18
$PAR::Packer::VERSION 0.982
Thank you for any hints, Christoph
file testpp.pl:
use Data::Dumper;
use Storable;
my $data = retrieve('testfile');
print Du
Hello,
packing a Tk applicatin with pp, I found that although Tk::FBox is
correctly detected and included, Tk::Bitmap is not.
Tk::FBox depends on Tk::Bitmap, maybe this should be added to the
Tk::FBox %preload entry (line 381 of Module::ScanDeps.pm)
Regards, Christoph Lamprecht
19 matches
Mail list logo
