Replying to myself again, but ...
When one PAR exe runs another PAR exe, two PAR environment variables cause problems,
PAR_PROGNAME and PAR_TEMP. Since PAR_TEMP is already defined, the second exe doesn't
create it's own cache directory and -C doesn't work. Since PAR_PROGNAME is already
defined, the first program may get re-run and "loops" can occur if -d is used.
Also, if the first exe is built with -C, the second exe runs with PAR_CLEAN=1 even if
it wasn't built with -C.
The work-around I mentioned below is overkill and prevents having systems defaults for
PAR_TEMP, PAR_CLEAN and PAR_DEBUG getting to the second exe.
On 17 Feb 2004 at 0:27, Alan Stewart wrote:
> I haven't figured out how to fix this the right way yet, but here is a work around
> that
> may work for you.
>
> Put this:
>
> for (keys %ENV) { delete $ENV{$_} if /^PAR_/ }
>
> right before:
>
> Win32::Process::Create($ProcessObj,
>
> in bar.pl.
>
> Something in the PAR environment variables looks already in progress and foo.exe
> isn't
> creating it's own cache directory, so there are "collisions" when foo.exe unpacks.
> By
> cleaning out the PAR_xx variables, I can get bar/foo to run with and without -C and
> -d.
>
>
> On 16 Feb 2004 at 21:30, Alan Stewart wrote:
>
> > I think I see a clue. When I build bar and foo without -d or -C, they run but they
> > are
> > unpacked into the same one and only cache directory instead of two dirs as I might
> > expect. Because of using Win32::Process, both prgrams are seeing the same progname
> > used
> > to create the sha1 cache name. When you try to use the -C option, one program
> > tries to
> > clear out stuff currently in use by the other (??) or overwrite stuff in use by
> > the
> > other (??) and the permissions error occurs. No clue yet what causes the looping
> > of
> > bar.exe when foo is built with -d.
> >
> > Hmmmm....
> >
> > On 16 Feb 2004 at 23:12, Jesse Schoch wrote:
> >
> > > It seems -d is effected as well. I may be able to get away without -d, but
> > > in my previous testing on NT 4 it caused problems. Also I noticed some
> > > loping problems, where the exec'ed pp built program would run over and over
> > > again, not sure what caused them, but deleting the cache seemed to help.
> > >
> > > Autrijus I kind of need -d, do you have any ideas?
> > >
> > > E:\test>pp -d -o bar.exe bar.pl
> > >
> > > E:\test>pp -d -o foo.exe foo.pl
> > >
> > > E:\1LinkMedia>bar
> > > BAR
> > > Permission denied at C:/Perl/site/lib/PAR/Heavy.pm line 127.
> > > Compilation failed in require at script/bar.pl line 2.
> > > BEGIN failed--compilation aborted at script/bar.pl line 2.
> > > exit code= 13
> > >
> > > E:\test>pp -o bar.exe bar.pl
> > >
> > > E:\test>pp -o foo.exe foo.pl
> > >
> > > E:\1LinkMedia>bar
> > > BAR
> > > FOO
> > > exit code= 0
> > >
> > > E:\test>pp -V
> > > Perl Packager, version 0.05 (PAR version 0.79_97)
> > > Copyright 2002, 2003, 2004 by Autrijus Tang <[EMAIL PROTECTED]>
> > >
> > > Neither this program nor the associated "parl" program impose any
> > > licensing restrictions on files generated by their execution, in
> > > accordance with the 8th article of the Artistic License:
> > >
> > > "Aggregation of this Package with a commercial distribution is
> > > always permitted provided that the use of this Package is embedded;
> > > that is, when no overt attempt is made to make this Package's
> > > interfaces visible to the end user of the commercial distribution.
> > > Such use shall not be construed as a distribution of this Package."
> > >
> > > Therefore, you are absolutely free to place any license on the resulting
> > > executable, as long as the packed 3rd-party libraries are also available
> > > under the Artistic License.
> > >
> > > This program is free software; you can redistribute it and/or modify it
> > > under the same terms as Perl itself. There is NO warranty; not even for
> > > MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> > > -----Original Message-----
> > > From: Alan Stewart [mailto:[EMAIL PROTECTED]
> > > Sent: Monday, February 16, 2004 10:27 PM
> > > To: Jesse Schoch; [EMAIL PROTECTED]
> > > Subject: Re: exec problems
> > >
> > >
> > > On 16 Feb 2004 at 21:47, Jesse Schoch wrote:
> > >
> > > > Here is a simple test. Let me know if anyone gets the same results.
> > > >
> > > >
> > > > E:\test>bar
> > > > BAR
> > > > Permission denied at -e line 640.
> > > > exit code= 13
> > > >
> > > > E:\test>perl bar.pl
> > > > BAR
> > > > FOO
> > > > exit code= 0
> > > >
> > > > _____________bar.pl___________________
> > > >
> > > > #!/usr/bin/perl
> > > > use Win32::Process;
> > > > print "BAR\n";
> > > > Win32::Process::Create($ProcessObj,
> > > > "e:/test/foo.exe",
> > > > "foo",
> > > > 0,
> > > > NORMAL_PRIORITY_CLASS,
> > > > ".")|| die &Error;
> > > > $ProcessObj->Wait(INFINITE )|| die &Error;
> > > > $ProcessObj->GetExitCode($exitcode)|| die &Error;
> > > > print "exit code= $exitcode\n";
> > > > sub Error
> > > > {
> > > > print Win32::FormatMessage( Win32::GetLastError() );
> > > > }
> > > >
> > > >
> > > > ____________foo.pl____________________
> > > >
> > > > #!/usr/bin/perl -w
> > > >
> > > > print "FOO\n";
> > > >
> > > > ____________build_____________________
> > > >
> > > > pp -C -o bar.exe bar.pl
> > > >
> > >
> > > You don't say how foo.exe was built, but I get the same error if either
> > > bar.exe or
> > > foo.exe has the -C option. If neither one was built with -C, it works for
> > > me.
> > >
> > > Alan Stewart
> > >
> > >
> > >
> >
> >
>
>
