blssu has asked for the wisdom of the Perl Monks concerning the following question:

I develop cross-platform Perl (Tk) applications. Most of the people running my applications don't have perl installed, so I bundle a minimal distribution of perl with all my releases. These usually end up between 5 and 10 MB depending upon the platform and modules used. The trick is figuring out exactly what parts of perl are needed. How do other monks solve this?

I'm not interested in encrypting or obscuring source code -- all my bundled Perl code is exactly the same as what I edit (commented, indented, etc.) I'm also not interested in archive formats or single binary executables.

Here are the two techniques I use.

The first uses brute force testing on a specially prepared perl install. After doing a normal kitchen-sink build and install, I run a Unix "touch" command to reset the last access times of all the files to Jan 1, 2000. Then I run my application (and test suite) to excercise every possible function. Finally I use a Unix "find" command to find all the files that have been accessed. This works well (even for Windows if I use Samba), but sometimes I miss autoloaded files if my testing script is incomplete. (Keyboard control of Tk scrollbars for example. Argh!)

My other technique adds a tracer subroutine to @INC that logs every require'd module. This works ok, but I have to guess what files were actually loaded based on the module name. Usually I grab entire directories containing shared object libraries and autoload files. I'm sure this technique is not generating minimal installs.

Replies are listed 'Best First'.
Re: How to minimize size of perl install?
by Massyn (Hermit) on Sep 10, 2002 at 09:56 UTC

    Yeah, you could do that... However, that seems like a lot of work!

    I suggest you look at Perl2Exe which compiles your code into executables. They offer packages that can create executables on almost every imaginable platform.

      Thanks for the link. The site doesn't describe the technique they use though -- it looks like a simple file bundler that works by scanning the source for require statements.

      I don't want to generate obscured or encrypted packages. I want people to be able to read and modify my code.

      The touch+find technique given above is actually very simple -- two Unix commands which I haven't even bothered to make a script for. The only down-side is that when packaging modules with lots of autoloads, you have to be sure your testing every execution path.