Duncan Murdoch wrote:
I'm one of the Windows maintainers for the R project (an open source
stats package). R allows users to build their own add-on packages; it
makes use of Perl scripts to put them together.
This makes extra work for Windows users to build their packages,
because they need to install Perl, set their path appropriately, etc.
I'd like to simplify the process.
One suggestion from a couple of users was to use pp to convert our
scripts to self-contained .exe files. We have about 20 scripts,
mainly with the same rather small set of dependencies, so this would
be kind of wasteful, and I've been thinking instead of putting all the
scripts into one .par file, and using parl.exe to run it. R normally
builds using ActivePerl, but I couldn't build pp there (I use MinGW
compilers, not MS) so I've been using a version built with Strawberry
Perl.
I've got a few questions. Bear in mind that I'm not very fluent in
Perl (others wrote the scripts), so some of the questions might be
very naive.
1. Is it possible to install scripts in subdirectories of script/
within the .par file? I'd like to run them as
parl foo.par subdir/baz.pl
This will let us keep the same organization of scripts as we have now.
2. Can you run a script that's not in the .par file, but look in
there for any modules it depends on? For example, I'd like to do
something like the line above even though subdir/baz.pl was not in
foo.par.
3. Can pp be packaged into a self-contained .exe file, or a .par
file? I tried, but when I was using it it complained. I did
pp.bat -o pp.exe pp
and then in the same directory under CMD.EXE things look okay, but
when running elsewhere under Cygwin, I see
$ pp rwver.pl
Module/ScanDeps.pm did not return a true value at PAR/Packer.pm line 35.
BEGIN failed--compilation aborted at PAR/Packer.pm line 35.
Compilation failed in require at pp.pm line 5.
BEGIN failed--compilation aborted at pp.pm line 5.
Compilation failed in require at script/pp line 5.
BEGIN failed--compilation aborted at script/pp line 5.
Is Cygwin the problem here?
4. Would there be license problems in distributing parl.exe and a
.par file produced by it with binary builds of R?
Thanks in advance for any answers.
Duncan Murdoch
>normally builds using ActivePerl, but I couldn't build pp there (I use
MinGW compilers,
There should not be any problem compiling Par::Packer with a MinGW
compiler in a Windows command prompt.
Others use Strawberry Perl with no problem, so I would stick with that.
However, just for the record, I have been using ActiveState Perl for
over two years with MinGW compilers. I do not use cygwin for compiling
even though I have it installed. I abandoned it after I got everything
to work in a Windows command prompt. I have to do
perl -MConfig_m Makefile.PL
instead of just
perl Makefile.PL
but otherwise the steps for nmake, nmake test, nmake install, are all
the same. ExtUtils::FakeConfig has to be installed.
On the other hand, people in the past have reported success with
cygwin. It has been a long time so I cannot state categorically that it
still works under cygwin.
In general, I would say yes to your item 1 above. From the tutorial at
http://search.cpan.org/dist/PAR/lib/PAR/Tutorial.pod,
% par.pl foo.par # looks for 'main.pl' by default
% par.pl foo.par test.pl # runs script/test.pl in foo.par
I also see nothing wrong with your first idea of just shipping all of
the .exe files separate. Yes it is wasteful as far as each one
including mainly duplicated resources. Trying to email them or send
them on floppies might be a challenge, but even the smallest pen/flash
drive should hold them all. I have a roughly 65K line suite of perl .pl
and .pm that pp packs as a single .exe that is just under 5MB in size.
Obviously the great majority of the 5MB is from the Perl, Tk and other
modules that I use, so I am guesstimating that each of your 20 or so
scripts will be about the same size when pp'd.
Hmmm. 5MB a pop. That is getting up there in size, isn't it? If that
is a problem I guess I would go with your idea #1.
>I'm not very fluent in Perl
If speed as well as compactness are the issues, again I do not know what
your needs are, you can make all of your .pl files in to your own home
grown modules (.pm files), and then make a new, generic main.pl file
that will be able to invoke all of the other said home grown modules,
including them with the "use foo" declarations. There will then be pp'd
.exe file made from the generaic main.pl that does the right thing (that
is, invokes the correct new module) depending on one or more arguments
given. The code should resemble that below.
------------------paste former_main_pl_01.pm
package former_main_pl_01;
use Exporter;
@ISA = qw(Exporter);
@EXPORT = ( "former_main_01", );
#--------------------
use strict;
#--------------------
sub private_01 {
....
}
#--------------------
sub private_02 {
....
}
sub former_main_01 {
my (@args) = @_;
.....
}
#--------------------
1;
-------------------------------end paste former_main_01.pm
-------------paste generic_main.pl
use former_main_01;
if ($arguments_call_for_former_main_01) {
($result, ..., $result_n) = former_main_01($arg1, ..., $argn);
}
*-----------*--end paste generic_main.pl
