> So how does code that expects non-library files like .mgk files, to be
> found in certain locations relative to other files work when they are
> not found? Of course, a lot of the .mgk files are "optional" and you
> get defaults when they are not found, but what if you don't want the
> defaults? (I probably do want the defaults, and so probably does the
> demo.pl expect the defaults, but... what if?)
>
> It seems more practical to me to keep the "standard Perl" directory
> structure, to minimize the amount of recoding needed to use PAR or not
> use PAR. One of my goals is to minimize and abstract behind common
> functions those hopefully few places where an application has to be
> aware of PAR.
>
If inc\ isn't extracted, then the non-lib files can't be found by any module
that isn't written to know about PAR. That's the whole reason for doing an
inc\ extraction. The structure of inc\ is the same as the original Perl lib
dirs and is added to @INC. If that works for the module, OK. If not, then not
OK.
Magick demo with --clean is quite likely using defaults.
> So, by experimentation, when I used --addfile, I "discovered" that the
> files wound up under inc/, and then chose a "path prefix" module that
> calculates the path prefix to "associated files" for the application.
> But if --clean doesn't extract inc/ then simple path manipulations don't
> provide the abstraction... it would need alterned techniques for both
> opening and reading the files as well, which is more invasive to
> "typical code that was designed without PAR in mind".
>
Do you know that you can use the --addfile to add in any location in inc\?
--addfile original\path\to\file;path\inside\inc\of\file
The resulting location may be a "standard" location where the app module will
find it
relative to @INC.
> Or am I missing something? I think the alternative to inc/ extraction
> for associated files requires a new interface for accessing those files?
> Or does PAR "tie" open/read/close so that access to files in the ZIP
> is transparent to the application? Or if it doesn't, would that be a
> good idea (for read-only files, of course)?
>
No. You'll either need to extract inc\ or be invasive in your code. PAR can't
possibly
hack into all file access in any unknown code transparently. Invasive, BTW, is
not that
much for code that wants to use PAR files directly. There is an easy function
to read a
file.
> OK, I look forward to this bug being fixed, then maybe I can get less
> confused. So two copies are not supposed to both be packed, and only
> libraries are supposed to be referenced by --link? But with the bug,
> two copies get packed, and non-library files also get packed? And the
> libraries get extracted to PAR_TEMP, and the non-libraries to
> PAR_TEMP/inc/shlib?
>
If this confuses you, I'd say don't do it. Using --link dir doesn't work
correctly and
isn't a documented option, but --link file does work. Use multiple --link file
options.
shlib\ is not a directory within inc\ within $PAR_TEMP. It is a directory in
the PAR zip
which gets extracted to $PAR_TEMP. Any file --link'ed is only packed under
shlib\ and
only extracted to $PAR_TEMP. Non-lib files are only up in the lib tree where
they always
were. When they are extracted, they are still in the lib tree under inc\. The
"bug" had
nothing to do with non-lib files.
Alan
