__FILE__ pseudo-literal breaks PAR::Packer executables?

[Terrence Brannon]

The following source tree:
https://github.com/metaperl/vcpaste/tree/master/paste/2011-09-09-21-50-11/packapp2

contains a single module, Some::File -
https://github.com/metaperl/vcpaste/blob/master/paste/2011-09-09-21-50-11/packapp2/lib/Some/File.pm

and a simple script to call a function in Some::File -
https://github.com/metaperl/vcpaste/blob/master/paste/2011-09-09-21-50-11/packapp2/somefile.pl

if you execute makefile.pl to produce a PAR::Packer version of
somefile.pl, Some::File fails to find it's own file.

__FILE__ appears to provide a relative path computed at compile time?
I wonder why the computed path was not made absolute?

At any rate, the packed file breaks and the unpacked one does not.

[Roderich Schupp]

On Sat, Sep 10, 2011 at 3:57 AM, Terrence Brannon <sche...@gmail.com> wrote:
> if you execute makefile.pl to produce a PAR::Packer version of
> somefile.pl, Some::File fails to find it's own file.
>
> __FILE__ appears to provide a relative path computed at compile time?
> I wonder why the computed path was not made absolute?

This code

   my $file = __FILE__;
   open(my $fh, "<", $file);

simply cannot work in a packed context: the file may not even exist as such,
as the code is compiled by reading from a zip archive.
In any case, __FILE__ is faked (using #line) to the name of the
unpacked file so that at least error messages contain useful information.

Cheers, Roderich