The thread "message before unpacking" inspired me to take the time to write this down.
Some time ago I was pointed at a different approach for packing perl packages. It turned out to work quite well. The basic idea is not unlike PAR/Packager (pp): gather all files needed and put them in a specific directory. Add a custom (native) loader program and you are set to go. The whole directory can be packaged using standard installers. This approach was brought to me by Oliver Betz. He used the name PPL (Portable Perl Loader), a name that stuck even though it is strictly speaking not correct. Oliver developed this initially for a big Windows application and I have extended it for Linux, MacOS and installers. While this doesn't sound very different from pp, is has a number of advantages. First advantage is that there is no such thing as 'initial run'. Second advantage is that there is no risk from losing files, which can happen if the kit is unpacked to temp storage as is the case with pp. Also, the location where the files are stored is well-defined. By using a custom native loader there is full control over the environment, e.g. it is possible to block the resultant application from (accidentally) using files and modules that may be present on the target system. Third advantage is that is is quite straightforward to turn a PPL kit into an AppImage (Linux), InnoSetup Installer (Windows) and DMG container (MacOS). I have done this sucessfully for a couple of big, wxWidgets based, perl packages. How it works: First step is to collect al the required files. There's an excellent tool for this: PAR/Packager. No need to reinvent wheels. Then I unpack the pp kit (using a small perl script). Depending on the platform and functionality some additional files (libraries) need to be added, and some need to be moved/renamed. When everything is in place I build the native loader program. This is essentially a stripped-down version of the perl loader, runperl.c. Note that this loader program is usually (nearly) identical for all applications. What happens next depends on the platform. For Windows I use InnoSetup installer to build a (real, native) installer. The InnoSetup control file is mostly boilerplate for all applications. For Linux I use appimagetool to turn the kit into an AppImage. For MacOS I use the create-dmg script (available on the net) to create a dmg. As always there are some pitfalls and complications but that is not different from any other approach. A fully functional example can be seen in the ChordPro project, https://github.com/ChordPro/chordpro/, directory pp . I hope this may be useful for other packages as well. -- Johan
