A framework for Perl executables

Hi all,

I have a couple of apps packaged with PerlApp 6.02. After a
few 
packages, I realise that these are all going to the same
machine, and as 
such should not have a need to pack the same Perl compiler
and libraries 
all the time into each executable.

I wonder if there is a framework of sorts for such a
situation, where 
the base libraries are stored in a known location, and
executables can 
be kept smaller (big files are not sexy for administrators),
yet the 
system does not need to install the full ActivePerl
officially.

Any thoughts on this matter is appreciated. Thanks.


_______________________________________________
PDK mailing list
PDKlistserv.ActiveState.com
To unsubscribe: http:/
/listserv.ActiveState.com/mailman/mysubs

On Sun, 08 Apr 2007, Foo JH wrote:
> I have a couple of apps packaged with PerlApp 6.02.
After a few
> packages, I realise that these are all going to the
same machine, and
> as such should not have a need to pack the same Perl
compiler and
> libraries all the time into each executable.
>
> I wonder if there is a framework of sorts for such a
situation, where
> the base libraries are stored in a known location, and
executables can
> be kept smaller (big files are not sexy for
administrators), yet the
> system does not need to install the full ActivePerl
officially.

PerlApp has support for this built in, with the --scan,
--use and --shared
options.  Assuming you have applications app1.pl and
app2.pl.

Create a shared library of all the modules used by your
application:

    perlapp --scan app1.pl --scan app2.pl --shared private
--exclude
            --script nul --exe mylib.dll

Then build the applications:

    perlapp --use mylib.dll --shared private --xclude
--runlib lib app1.pl
    perlapp --use mylib.dll --shared private --xclude
--runlib lib app2.pl

Then put app1.exe and app2.exe into one directory, create a
"lib" subdirectory
there, and put mylib.dll and perl58.dll into this
"lib" subdirectory.  It is
best *not* to use the default runlib directory, because if
you put your
application directory on the PATH, then you also put a copy
of perl58.dll on
the PATH, which may interfere with other Perl installations
on the target
machine.

In PDK 6 on Unix each executable has a statically bound copy
of libperl;
if you want to use --xclude on Unix, you need to upgrade to
PDK 7.

With PDK 7 you can also have perl58.dll (or libperl.so)
loaded from your
shared library. In that case you don't use --xclude on the
lib, and you
don't really need to use a separate runlib directory:

    perlapp --scan app1.pl --scan app2.pl --shared private
--script nul --exe mylib.dll
    perlapp --use mylib.dll --shared private --xclude
app1.pl
    perlapp --use mylib.dll --shared private --xclude
app2.pl

Now put app1.exe, app2.exe and mylib.dll into a single
directory.

Cheers,
-Jan


_______________________________________________
PDK mailing list
PDKlistserv.ActiveState.com
To unsubscribe: http:/
/listserv.ActiveState.com/mailman/mysubs

Hello Jan,

Thanks. I think this is what I need!

Jan Dubois wrote:
> On Sun, 08 Apr 2007, Foo JH wrote:
>   
>> I have a couple of apps packaged with PerlApp 6.02.
After a few
>> packages, I realise that these are all going to the
same machine, and
>> as such should not have a need to pack the same
Perl compiler and
>> libraries all the time into each executable.
>>
>> I wonder if there is a framework of sorts for such
a situation, where
>> the base libraries are stored in a known location,
and executables can
>> be kept smaller (big files are not sexy for
administrators), yet the
>> system does not need to install the full ActivePerl
officially.
>>     
>
> PerlApp has support for this built in, with the --scan,
--use and --shared
> options.  Assuming you have applications app1.pl and
app2.pl.
>
> Create a shared library of all the modules used by your
application:
>
>     perlapp --scan app1.pl --scan app2.pl --shared
private --exclude
>             --script nul --exe mylib.dll
>
> Then build the applications:
>
>     perlapp --use mylib.dll --shared private --xclude
--runlib lib app1.pl
>     perlapp --use mylib.dll --shared private --xclude
--runlib lib app2.pl
>
> Then put app1.exe and app2.exe into one directory,
create a "lib" subdirectory
> there, and put mylib.dll and perl58.dll into this
"lib" subdirectory.  It is
> best *not* to use the default runlib directory, because
if you put your
> application directory on the PATH, then you also put a
copy of perl58.dll on
> the PATH, which may interfere with other Perl
installations on the target
> machine.
>
> In PDK 6 on Unix each executable has a statically bound
copy of libperl;
> if you want to use --xclude on Unix, you need to
upgrade to PDK 7.
>
> With PDK 7 you can also have perl58.dll (or libperl.so)
loaded from your
> shared library. In that case you don't use --xclude on
the lib, and you
> don't really need to use a separate runlib directory:
>
>     perlapp --scan app1.pl --scan app2.pl --shared
private --script nul --exe mylib.dll
>     perlapp --use mylib.dll --shared private --xclude
app1.pl
>     perlapp --use mylib.dll --shared private --xclude
app2.pl
>
> Now put app1.exe, app2.exe and mylib.dll into a single
directory.
>
> Cheers,
> -Jan
>
>
>   

_______________________________________________
PDK mailing list
PDKlistserv.ActiveState.com
To unsubscribe: http:/
/listserv.ActiveState.com/mailman/mysubs