Mark Dootson wrote:
> That is where a shared library is loaded in a completely none standard
> manner for the operating system concerned.
> This is the case with Gtk2, and to a lesser extend with Wx (you can
> alter Wx within Perl so that libs are loaded using current PAR
> implementation).
This is also my understanding.
> and Module.dll has a dependency on ModuleExtra.dll, then if
> ../auto/My/Module/ModuleExtra.dll exists, that will get loaded .
> If later in my prog I do "loadlibrary('ModuleExtra.dll') then I will
> just get an increase in the ref count to ./auto/My/Module/ModuleExtra.dll.
Though I'd rather not package external libraries (ModuleExtra.dll in the
example) in those directories. While it works, it may break in other
cases or just clutter the .par and /tmp with multiple copies.
> In the odd case of Gtk2, the only way to cope with its behaviour is to
> extract to a standard 'tree' (as pointed out earlier in thread).
[...]
> Why not take recent work on Archive::Unzip::Burst and incorporate that
> in a reworked PAR - say PAR::Burst
One problem with Archive::Unzip::Burst is that it doesn't work
everywhere. That's why it's used by PAR and friends if it's available
and if not, things fall back to Archive::Zip.
Also, there's a difference between
- what PAR.pm does when loading a .par,
- what parl does when running a pp-created executable,
- what parl does when running a pp-created executable in CLEAN mode.
A::U::B is only used in cases 2) and 3)(?) right now.
> PAR::Burst would then just extract everything to cache directory with no
> name mangling and a simple tree structure like
>
> inc
> shlib
> script
>
> 'inc' gets added to @INC, shlib to library paths, script folder is added
> to 'PATH' and perms mask is 0755.
>
> End users can add whatever else thy like to zip structure.
>
> Of course, this would mean that foo.par packed under PAR would be
> different to foo.par packed under PAR::Burst - so PAR::Burst would need
> a fallback method whereby after extraction, if we don't have
> 'PAR::Burst' structure, start again with PAR. This would make older .par
> files take slightly longer to load, but it would still work until all
> dependencies were converted to PAR::Burst
So far, this isn't so much changed from the current PAR except that we'd
extract everything upon loading a .par file (first case above) and that
there's no mention of the hashed files which are extracted from parl
itself for bootstrapping. Is that right?
The extraction layout doesn't look that much changed to me.
> For PAR::Burst::Packer, the goal would be to incorporate the unzip code
> directly within the compiled executable, removing the need to load Perl
> at all until after the extract is complete.
This is the really deep change. Incorporating infozip code might force
us to go GPL only, too. I've always been a bit scared about what this
really means wrt A::U::B. That's why that module has an unmodified copy
of the InfoZip sources. Maybe InfoZip has a clause that lets you compile
it into self-extracting executables without violating or adopting the GPL...
> In addition to increased speed, this would give us the huge advantage
> that when the initial executable stub has extracted the zip tree, we can
> then in the extracted second executable simply mangle the arguments and
> call
> perl_parse on the path to the extracted script - removing any BEGIN,
> eval, do -e wrapper. We would have to prepend a BEGIN block to the
> script to set up necessary PATHS / @INC but this would still make the
> script code that followed run exactly as if it have been called as "perl
> myscript.pl". A big win I think.
I agree that this would be a big win. Did you know CHECK and INIT blocks
don't work in PAR packaged executables for this reason?
However, I'm not sure whether it's worth the trouble to make it compile
everywhere, including a zip implementation. That's up to you if you want
to work on it.
Now, if you compare this to current Packer+A::U::B, then the main
difference is the order of what happens. Not much change for the user,
except for advantages:
- no hashed files from bootstrapping,
- a bit faster,
- CHECK & INIT,
- we can finally fix the bug that the temporary directory name of "parl
foo.par" only depends on parl, not on foo.par...
> I would quite like to work on this if there is any agreement that any of
> it represents a reasonable idea.
Unfortunately, I'm somewhat opposed to creating something which amounts
to a full fork of PAR::Packer. It's hard enough to maintain as it
stands. Also, this whole scheme kind of goes in the opposite direction
of what Scott Stanton has been doing wrt to loading Perl modules from
memory. I'm not sure which way is right -- I guess that really depends
on the case at hand.
Something that worries me is that if you have a large library of .par
files and do "use PAR '*.par';", you only pay for what you actually load
right now. If we extract everything on load, this (valid) use case
really breaks.
So if you would like to work on this, that's fine. If I can help, I will.
I'd try to change the default parl(dyn?!) to burst-unzip into the
temporary directory, set up the paths there, and *then* start the perl,
as you outlined. But we can't do this full extraction for PAR.pm and
.par's, see above.
What I'm still not sure about is what to do wrt to CLEAN mode and
loading .pm's from memory (which isn't in the main dev line yet).
Best regards,
Steffen
