On Nov 27, 2007 11:05 PM, Scott Stanton [EMAIL PROTECTED] wrote:
Steffen Mueller wrote:
That's actually a good idea: Avoiding dll file name clashes using a
directory for each external (non-perl-module) dll. Currently, we
extract
the external dlls under their original name, IIRC.
Scott Stanton schreef:
It seems like Windows
is very bad at creating lots of small files
Which Windows version? Anti-virus involved?
--
Affijn, Ruud
Gewoon is een tijger.
The intent isn't to avoid name clashes within a single application, it's
to avoid version clashes across applications with a shared cache
directory. Instead of creating a separate cache-sum directory for
every application, you can share a single cache directory as long as
files are given
I've seen slow behavior on Windows XP SP2 and Windows 2003. My machine
has the Trend Micro anti-virus client running on it. I've tried
disabling the anti-virus software and it definitely speeds things up,
although it's still quite a bit slower than Linux. Unfortunately
telling our users that
On Nov 28, 2007 5:42 PM, Scott Stanton [EMAIL PROTECTED] wrote:
The intent isn't to avoid name clashes within a single application, it's
to avoid version clashes across applications with a shared cache
directory. Instead of creating a separate cache-sum directory for
every application, you
I'm trying to ship a self contained application to our customers. We
are not allowed to dictate to the customer what versions of perl and
installed packages they may have on their machine outside of our
installation directory. They may not even have an installed perl. We
certainly can't rely on
Hello. I'm having difficulty building PAR::Packer. I'm running OSX 10.5.
I've downloaded the svn from
http://svn.openfoundry.org/par/PAR-Packer/trunk/ and am trying to compile.
However, I get the following:
[EMAIL PROTECTED]:~/Install/Sources/par-packer $ make
include
On Nov 28, 2007 6:39 PM, Scott Stanton [EMAIL PROTECTED] wrote:
I'm trying to ship a self contained application to our customers. We
are not allowed to dictate to the customer what versions of perl and
installed packages they may have on their machine outside of our
installation directory.
Well, sort of. I need a solution that is portable across Solaris,
Linux, Windows, MacOSX, HP-UX, etc. with minimal fuss.
A pp app gives me portability and simplicity of installation (i.e. no
installation required). The user can simply copy the binaries anywhere
they like and it just works. I
