Hi Duncan,
Duncan Murdoch schrieb:
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.
thanks for the most excellent R tool/package/language!
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.
As for PAR::Packer not building for AS Perl with MinGW: For some reason
that's beyond me, the Makefile in the myldr subdirectory is generated
with some options specific to the Microsoft compiler. PAR::Packer *can*
be built with AS Perl+mingw, but you need to remove/replace some options
in the gcc commands. (I think replacing --libdir with -L or so does it,
but my VMWare-Windows installations have been wiped.)
However, you can install PAR::Packer as a binary for AS Perl using PPM.
The bribes.org repository as well as Randy Kobes' repository have up to
date versions. (Kobes: http://theoryx5.uwinnipeg.ca/ppms/ Bribes:
http://bribes.org/perl/ppmdir.html)
That being said, Strawberry Perl should be fine and PAR::Packer should
absolutely build out of the box.
There are several ways to go about your problem. Most certainly,
packaging each script using pp into its own executable would blow up the
size of the R package by a huge chunk. You're right: Not a great idea.
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.
This is possible, but I have to admit I never thought about this before.
There is no *easy* way to do this, but it seems to work. It's not
documented behaviour, but I can't think of a reason of it not working
any more in the future. Whether or not that's enough for you to choose
to use this "feature" is up to you.
So, to get that behaviour given foo.pl and bar.pl which should go into
the myStuff subdirectory: (Assuming a *nix shell. Should be simple to
translate to cmd.exe given you have some unzip tool.)
pp -o t.par -p foo.pl bar.pl
mkdir blib
mv t.par blib
cd blib
unzip t.par
rm t.par
mv META.yml ..
mkdir script/myStuff
mv script/foo.pl script/myStuff/
mv script/bar.pl script/myStuff/
cd ..
Now, edit META.yml and add two lines:
name: SomeNameIDontCare
version: 0.01
Then:
perl -MPAR::Dist -e 'blib_to_par'
Done:
parl SomeNameIDontCare-0.01-Win32...-5.8.8.par myStuff/foo.pl
(runs foo.pl)
Of course, you can rename the resulting .par file. I understand this is
something you have to do and not the users. It should be easily
scriptable if necessary.
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.
Yes:
use PAR 'foo.par';
use Bar; # will load Bar.pm from the .par if possible.
That requires a PAR.pm with dependencies that's available to the script
somehow before loading foo.par. Of course, if you're running this from a
script which is coming from a pp packaged executable or .par, PAR is
already loaded and this works to load stuff from a different .par
archive. (Or even from a pp packaged executable. "use PAR 'foo.exe';"
should work.)
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?
I don't have the slightest idea. But you can install pp via ppm from the
above mentioned sources.
4. Would there be license problems in distributing parl.exe and a .par
file produced by it with binary builds of R?
I don't think so. Audrey Tang holds the copyright to almost all
PAR-related distributions. She released PAR under the same terms as perl
itself which is, at your choice, either GPL or the "Artistic License".
I'm no lawyer, but even if R is not under the GPL or if it wasn't Open
Source at all, it should be legal and certainly intended that you can
redistribute a parl.exe. Adding a copyright notice somewhere in the
documentation or README or so should take care of things.
Furthermore, the .par's or .exe you generate yourself from your code are
absolutely yours to do with as you like. Except, of course, if they
contain modules from authors who did not license their modules under a
non-free license. But that's entirely unrelated to PAR.
If something is unclear to you, feel free to ask. If you like, you can
skim the PAR FAQ on par.perl.org. It contains a lot of good ideas for
various use cases.
Hope this helps,
Steffen
