Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Would Cava Packager [cava.co.uk] suit your needs?

    I'm currently testing it for deploying some wxPerl applications. It is working quite well for me so far.

    Thought it might be worth mentioning.

    • Thanks. I had never heard of Cava Packer before, so I'm glad you brought it to my attention.

      I'm not sure what to think of it, so here's a list of my impressions:

      • I definitely don't like the fact that a program that is written in Perl, requires installation as administrator. WTF?
      • Though the GUI looks nice, it's also too hard to use. The first time I tried to use it, I really needed to follow the walkthrough example from the help file to get my first executable file compiled. I was totally lost without it.
      • Hi, I'm the developer behind Cava Packager.

        Installing as Admin - that's an error on my part with the installer. The application certainly does not need admin privileges. I'll ensure the next upload has this requirement removed.

        I am aware that the GUI has become confusing. I should have realised this when I decided it needed a 'quick start' guide. I'll be fixing that by adding a 'new project' wizard in the short term that takes you through minimum steps necessary to package a script, followed up by a redesign of the whole thing.

        Having read your comments on the file layout - I think you are right. My only requirement was that the executable should not be in the same directory as perl58.dll. As you say, it would make sense to have the executable(s) in the root of the build tree.

        The mapping of file names isn't intentionally opaque. It just didn't occur to me that there would be a practical reason to need to know the mappings. I'll output mappings to logs in the next version.

        All the files in the build directory are required. (Or at least the scanning process thinks they are required.) The first action on each build is to completely clear out the directories. Scanning does not write any files. If your script requires utf8 or POSIX somewhere in its dependencies, you will get a huge number of files. I guess providing mappings between 'real' file names and packaged names would make this whole aspect less opaque.

        With regard to keeping the files separate, and not archiving them into a single file - that was the main reason for starting the project. PAR / pp gives a perfectly good archived/packed solution - I wanted a portable (between machines) tree that could run off a USB without the need for temp files. Working with wxPerl also means relatively huge DLLs - though I could live with the slow first time startup if that were the only drawback for my particular requirement.

        You can package in a completely transparent way, without any renaming or attempting to obfuscate the source files on disk. I'd agree that it isn't immediately clear that this is an option.

        Going back to your original question, my advice would be to start with PAR::Packer.
        if
        pp -o your.exe yourscript.pl
        works for you, perhaps you could learn to live with the temp dirs?

        Thanks for the constructive comments.

        Mark