Thanks for the clarification, Markus. I've applied a modified version of your patch as change 82af41c8ab2dd061acd7deb9979fa6cb5c4725ae. You can review it online at https://github.com/rcaputo/poe-component-resolver
-- Rocco Caputo <rcap...@pobox.com> On Jul 29, 2011, at 05:01, Markus Jansen wrote: > ... tiny correction of ^$X listed below, sorry for the typo ... > /Markus > > -----Original Message----- > From: Markus Jansen [mailto:markus.jan...@ericsson.com] > Sent: Friday, July 29, 2011 10:40 AM > To: Rocco Caputo; POE Mailing List > Subject: RE: Problem to execute "sidecar" Perl scripts when compiling > POE::Component::Resolver 0.912 with PAR > > 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" > @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:rcap...@pobox.com] > 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 <rcap...@cpan.org> > 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 <rcap...@pobox.com> > > > 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 >
