CCing to the PAR mailing list again...
On Thu, Nov 27, 2008 at 12:36 PM, Manoj Bhatti <[EMAIL PROTECTED]> wrote:
> Hi Roderich,
>
> Your right, it is kinda chicken and egg problem. My Visual C++ app uses the
> Perl API discussed in the perlembed doc. I created an embedded perl
> interpreter in my Visual C++ app and my perl script called 'download.pl', is
> loaded by first calling perl_parse("download.pl") and then secondly calling
> the perl API function call_argv() and invoking a perl method called
> 'exec_download'. All of this is described in the perlembed doc. This is
> working fine. Now in for deployment I don't want the download.pl and my perl
> module called 'Download.pm' to be visible to the user and also for cleaner
> deployment.
Understood.
> I read about the PAR functionality and found it interesting. I noticed that
> par.pl or parl has a -B option to package the core modules required by my
> download.pl and the script itself into a .par file, which I understand is
> like a zip compressed file. I really dont need to hide my script from the
> user, but my real need is to deploy the core perl modules and my download.pl
> in a cleaner way (which .par is perfect for) with my Visual C++ .exe. The
> real problem for me is to understand whether it is possible or not - to
> execute par.pl or parl(which has it own embedded interpreter) within my app
> having its own embedded interpreter ? If PAR.pm has to be deployed, then it
> is indeed a chicken and egg issue ....
Definitely. It's not only that you need PAR.pm. You also need any module that
is use'd by PAR.pm. E.g. Archive::Zip is used to access the stuff in
the .par file
(which is just a zip file). You also need several Perl core modules.
And you need to ship the Perl runtime DLL that you linked into your .exe
(OK, you could link a static version of the runtime to get around that).
Executing a .par build with -B needs either an installed Perl or parl which
is a "standalone" Perl interpreter wihth the above mentioned stuff
somehow built-in
to solve the chicken-and-egg problem. (Building a freestanding executable
with pp then is conceptually just concatenating parl with a .par of the actual
script plus all its dependent modules).
Neither of these solutions will solve your problem. Of course, you could
amend your embedded perl interpreter to have the capabilities of parl,
but that's a lot of messy work. I suggest another approach:
How is the interaction between your embededded perl interpreter and
the rest of your application? Would it be possible to just spawn a
Perl process to run the script, pass some parameter to it via the command
line or writing to a pipe and get the results back via another pipe?
Then you could pack the script and all needed modules into one
standalone executable (using bog-standard pp) and spawn that instead.
> Have any other users of PAR ever used it in an embedded environment ?
Not that I'm aware of (just grepped the PAR mailing list).
I once heard a talk by Marc Lehmann (MLEHMANN on CPAN) where he
described his work of building a Perl interpreter with all needed modules
compiled in. If memory serves the goal was to run this executable
in an embedded router where there might not even by something like
a filesystem where to load modules from. But he had to jump to all kinds
of hoops to make it work and AFAIK his work has never been published.
Cheers, Roderich
