Hi Rocco,
thanks for coming back on this issue. Using the
POE::Component::Resolver::Sidecar module
is a good idea, though IMHO Module::ScanDeps should know that the module is
needed via the
use of "\&POE::Component::Resolver::Sidecar::main" for Windows.
The main problem is that while the [suboptimal] Windows solution would work for
PAR,
the standard [preferred] Unix solution does not for a number of reasons:
- within PAR,
$^X is set to "perl"find
@INC is set to [ "<par_unpack_path>/inc/lib", "<par_unpack_path>/inc/",
CODE(......), CODE(......) ]
- a "perl" executable does not exist inside the packed code (that is, at
runtime under <par_unpack_path>)
- instead, there is a "limited Perl interpreter"
- one of the limits is that this interpreter cannot execute perl
scripts via -e
Each of the above effectively spoils the intended "$^X -I @INC -M...Sidecar -e
'...Sidecar->main()'",
i.e. the Sidecar execution via exec().
Due to the lack of -e support, one has to put
use POE::Component::Resolver::Sidecar;
POE::Component::Resolver::Sidecar->main();
into some ...Sidecar.pl file, and get that called.
In the meantime, I have found that there are at least two ways to pack the
above mini-script
into a PAR executable (whether using the experimental --reuse switch or not is
one of the details)
and to get it called; hence, I would not like to dictate PAR users which of
those ways to take,
nor any naming conventions regarding the intermediate Sidecar.pl perl script.
As a result, supplying the possibility to specify $sidecar_program seems to me
the only general and lightweight way forward.
Perhaps the change should come with a comment that the intended use is for PAR
and similar modules,
and should be used by experts who think they know what they are doing :-).
Anyhow, my patch works great in production with the latest/greatest 2 PAR
versions.
Best regards,
Markus
-----Original Message-----
From: Rocco Caputo [mailto:[email protected]]
Sent: Friday, July 29, 2011 6:54 AM
To: POE Mailing List
Cc: Markus Jansen
Subject: Re: Problem to execute "sidecar" Perl scripts when compiling
POE::Component::Resolver 0.912 with PAR
Hi, Markus.
It would seem that PAR (and other packaging tools?) can't find the Sidecar
module because I neglected to actually use it. Please see the included patch,
which resolves the missing Sidecar problem for Windows and anything else that
detects "use" statements in the source.
Do you ever supply a sidecar that isn't POE::Component::Resolver::Sidecar? A
parameter would be excellent for a general-purpose sidecar-based module, but I
think it's not so useful here.
commit 638cd9e616a5b4ffbf413672784f41896de97430
Author: Rocco Caputo <[email protected]>
Date: Fri Jul 29 00:44:00 2011 -0400
Load the POE::Component::Resolver::Sidecar class.
The presence of this module is requested on MSWin32. Resolves
rt.cpan.org ticket 69172, reported by Gabor Szabo.
diff --git a/lib/POE/Component/Resolver.pm b/lib/POE/Component/Resolver.pm
index ff7ec8b..6614189 100644
--- a/lib/POE/Component/Resolver.pm
+++ b/lib/POE/Component/Resolver.pm
@@ -9,6 +9,8 @@ use Time::HiRes qw(time); use Socket qw(unpack_sockaddr_in
AF_INET AF_INET6); use Socket::GetAddrInfo qw(:newapi getnameinfo
NI_NUMERICHOST NI_NUMERICSERV);
+use POE::Component::Resolver::Sidecar;
+
use Exporter;
use base 'Exporter';
our (@EXPORT_OK) = qw(AF_INET AF_INET6);
--
Rocco Caputo <[email protected]>
On Jul 15, 2011, at 06:17, Markus Jansen wrote:
> Hi Rocco,
>
> based on the excellent input I got so far from you and Steffen, I have now
> found a simple solution on the POE side
> without any assumptions towards PAR (or whatever special system used, even
> with PAR there is more than one way to do it :-).
>
> The idea is simply to make $sidecar_program configurable, and leave the
> solution details to the application if special ones are needed.
> Find a possible [tested] patch below, and please consider it for integration
> in POE::Component::Resolver 0.913.
>
> Best regards,
>
> Markus
