On 6 Jul 2004 at 9:41, Dean Arnold wrote:
> If I follow your processing sequence, the best (or at least quickest and
> most general solution) might be to add an option to include startup native
> executables in the PAR bundle that PAR can start via fork() or some such,
> then maybe capture the executable name in $ENV associated with its PID.
> Then when the primary application finally gets loaded and fired up,
> the app can check $ENV for the startup(s) and kill them if desired.
>
I don't have any clean good ideas on how to do it. Forking leaves the chance for
zombies if the application croaks. Also, any scheme has to be conditionally included,
so those who don't need it, don't pay for it. parl.exe and parldyn.exe are currently
pre-built with only the required modules needed for unpacking. Having a conditional
facility in them would mean switching to some kind of dynamic build.
Whatever might work is probably going to require some significant re-working of the
current code. Anyway, I'm not motivated to tackle this. The first thing I do is turn
off any splash screens, no matter how slow a program might be. If it's a useful
program, I know what's happening, after 20 or 30 times.
BTW, if you don't use pp -C, the modules are all still in the temp cache the second
time around and not unpacked again. Subsequent executions should start faster.
> Likewise (getting back to my earlier issue w/ trying to read() included files,
> could PAR generate a $ENV value that points to the temp directory
> where it keeps its storage ? (I think thats how perl2exe did it).
>
I should have mentioned that before. The -a option is a recent addition that I haven't
actually used yet. $ENV{PAR_TEMP} is there already, and -a files are extracted to the
$ENV{PAR_TEMP}."/inc" dir. For example, using -a and aliasing:
pp -a original_dir/some.txt;another_dir/renamed.txt -o t.exe t.pl
would extracted a copy of original_dir/some.txt as:
$ENV{PAR_TEMP}."/inc/another_dir/renamed.txt"
Alan Stewart
