Glenn Linderman schrieb:
On approximately 11/7/2006 2:13 AM, came the following characters from
the keyboard of Steffen Mueller:
--> Leave parl as it is and embed a stripped down version into a pure
data module (PAR::StrippedPAR::Static and PAR::StrippedPAR::Dynamic
respectively) which is created at PAR build time.
So the stripped down version you embed is likely one that has never been
completely "dressed" with all the modules in the first place? Which was
a step in building parl anyway? So you just carry that forward into the
PAR installation....
Yes. It is a copy of "static.exe" in myldr/ and a copy of "par.exe" for
parldyn.
--> Extract that parl-without-embedded-modules for each pp call and
use it for packaging binary executables.
"use it" here, means [use pp to package it together with the necessary
modules, including the ones that are part of the former "dressing" which
get added in because they are needed] rather than [run the stripped parl
to created the binary executables.]
pp (or rather: PAR::Packer) has a system call in it which calls parl (of
whatever type) to do the packaging. I modified it to extract the
"stripped" parl and use that instead of the usual parl.
The reason I chose to embed the stripped parl into a module over
adding another (two: static & dynamic) executable files to scripts/
was that the latter approach might have caused confusion when
"strippedparl" or so wouldn't work as advertised.
So if the "dressed" parl isn't suitable for use by pp on machine b to
build a binary executable that works on b or c, why is it deemed
suitable for using at all on machine b?
parl is the PAR Loader. You can "parl foo.par". If the machine doesn't
have the necessary modules+perl, that should fail with the stripped parl.
Wouldn't the same situations
arise, if parl (which runs partially packed code) was called upon to
invoke those same incompatible XS modules (albeit unpacked), because
they were referenced by some of the code that was packed?
I don't understand.
Meaning, while I think you are fixing some of the problems, probably all
of them for packed pp standalone executables (which is the only kind of
PAR I use anyway), it doesn't seem to be quite a complete solution? [...]
Solution to what? It doesn't fix all PAR bugs, but it should surely fix
the bugs which are introduced by remnants of the PAR-building system
because except for the perl itself, it doesn't bundle modules into the
parl that will be used by pp.
Steffen
