As per my most recent mail, this solution isn't complete:
Steffen Mueller schrieb:
- Solution:
--> 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.
--> Extract that parl-without-embedded-modules for each pp call and use
it for packaging binary executables.
What's missing is embedding the relevant modules into the extracted,
stripped parl when running pp. That is basically just one more step as
in the myldr/Makefile:
New strategy:
- extract stripped parl
- run stripped parl with these arguments:
(map {"-I$_"} @INC), '-q', '-B', "-Orealparl$EXE_EXTENSION"
- "realparl(.exe)" is now the full parl with the packaging system's core
modules.
- use realparl for packaging (i.e. append .par)
- delete both intermediate steps (extracted stripped parl, real parl
I tried this with a hackish approach (on win32 as well) and it works.
Doesn't exactly make pp faster, of course.
Is this worth the effort or should we go back to the current behaviour?
Glenn: Of course, this doesn't affect the "parl foo.par" use on the
machine which has PAR. The parl.exe built at PAR build time might still
have old versions of the perl code. The reason why we can't do anything
about that is simple: pp is something of a "compilation" step which can
do all sorts of things to the output. Just running "parl ..."
conceptually can't do that. The only thing we can do is replace the
concept of "parl" completely. But that's something for somebody else and
at some other time. I cannot do that.
Steffen
