in reply to Re: Extend known installation processes to include modules
in thread Modules or lack thereof

I think we're moving out of context here. Mainly I was railing against those that invent the restriction even though they already have invented or have decided to invent a method of distributing their code to, say, 100 other systems. Even if it's the equivalent of a .zip file. Just put the modules and its pieces in a subdirectory of your build directory, add a 'use lib' pragma, and it should work, no? My only concern is those modules that need to load a shared library of some sort when starting up (libnet?). Is it feasible to re-locate an item like that?

Hell, even if you can't relocate, why can't you just *add* those directories in your archive. It's not like each module must be re-installed on the target machines (unless they're different OS's). Just pack up something like this:

c:\myapp\ c:\perl\site\lib\Net\ c:\perl\site\lib\OtherModule\
Assuming Perl is installed in the same place on each system, your simple .zip distribution process would work. That's why I'm saying it should be trivial to extend an existing installation process.

Even an InstallShield installation should be able to adapt to something like this. All the modules are are additional files that need to be unpacked under the Perl root. I suspect the toolkit has means for detecting this directory. Just install your modules and supporting binaries as you would any DLL!