On approximately 5/18/2009 1:12 PM, came the following characters from
the keyboard of Mark Dootson:
Hi All,
Ben Morrow wrote:
I've just looked at it now... It looks as though it will do some of what
I want, but I don't really like not being able to see what it's doing.
I agree too. It was an error not to OS, but one I'm stuck with in the
short term.
I do have a very simple replacement that currently has no GUI but I use
in real world applications.
Is the replacement OS? Who needs a GUI?
Deployed applications have two side by side directories -
.../bin
.../lib
Executable in bin. Everything else in 'lib' - that's a full @INC tree
(for modules used) plus perl5x.dll and main script.
Exec does 3 simple things.
1. Utilises a delayed load for Perl5x.dll - so code figures out where
Perl5x.dll is relative to 'bin' dir and loads it.
2. reworks args so I get the equivalent of
-I../lib ../lib/scriptname.pl all other arguments
3. Passes this arglist to RunPerl
And that's it. Passing the script name in this way rather than passing
perl code directly insulates you from any number of issues.
Not clear here... the deployed applications is a .exe that unpacks
.../bin and .../lib, and run runs the executable in .../bin? Or the
deployed application is packaged by some installer, but has the
structure mentioned, thus not depending on installed Perls?
All that's needed then is method of your choice to determine
dependencies :)
And a link to the replacement, so we can play?
--
Glenn -- http://nevcal.com/
===========================
A protocol is complete when there is nothing left to remove.
-- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking
