Hi Steffen, Steffen Mueller schrieb:
> Why not pp? Because you seem to want to package all that's in D:\lib. If > that's not the case, use pp. The approach outlined above skips the > dependency scanning which pp normally performs. It's basically just > making a ZIP file (with .par extension) from your lib. The > generate_blib_stub step just generates the META.yml (and creates the > blib dir). Since the .par will contain everything below "blib" > (excluding the "blib" directory itself), you could get away by just > creating a ZIP of the lib directory. But you would lose any meta info. > > Does that make sense? > Not really - what I want to have is the following: I've got installed the "basic" Perl-Distribution (for example ActivePerl) on my machine. Additionally I've got a couple of perl-modules installed from CPAN or PPM. Using this I develop my own modules (D:\lib) and scripts. The scripts are based on my own modules. Now I want to bundle the additional perl modules and my own modules into a par file, so I can port the par-file to other machines - which only have the "basic" Perl-Distribution installed ... I want to avoid to install the additional modules on the other machines ... I could build an executable out of each script, but since all scripts base on the same fundament (additional Modules and D:\lib), I would prefer avoiding the redundancy using the approach above ... (and due to other reasons ...) Greetings Johannes -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
