> That's not what I wrote. It's not enough that tkIcons is > somewhere included in the zip archive. It must be included > as "lib/tk/ToolBar/tkIcons". Then it will be found (at least here > on Linux) by Tk->findINC without messing with @INC > (I ran the packaged example under strace to make sure > that it really grabbed tkIcons from the zip and not > from a local file.) > To get pp to include a file in the zip in a specified location > use the notation > > -a "real/path/to/file;path/to/file/in/zip" > >> pp -o tb.exe -a "C:/Perl/site/lib/Tk/ToolBar/tkIcons" tb.pl > > The above will most likely include the file in the zip as > "Perl/site/lib/Tk/ToolBar/tkIcons" which is _not_ want you want. > >> This prints imgF: >> When I include unshift @INC, 'C:/Perl/site/lib'; in the >> original script and package the same way, print returns >> imgF: C:/Perl/site/lib/Tk/Toolbar/tkIcons >> >> So something could be wrong with par packaging @INC on >> windows which does include the above mentioned path. > > No. You _don't_ want a packaged script to have anything > from your disk in its @INC, because > - what will the executable load when run on a machine > with no perl installed? > - or worse: what will the executable load when run on a > machine with a different version of perl installed > or with a different version of the module to be loaded? > The whole point of packaging (at least for me) is to create > a programm that will run on any machine (with the > same OS) _in the same way_ regardless which perl and modules > it's got installed or whether perl is installed at all. > > Cheers, Roderich
Thank you for clarifying. I didn't realize one has to list a zip path for including an aditional file. Regards Radek H.
