Slash Boxes
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.
More | Login | Reply
Loading... please wait.
  • Would Cava Packager [] 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. Not good. GUI's are supposed to make things simpler, aren't they?

        The root of my confusion is the requirement of a "project", where it is initially not clear what it is for. It doesn't use a default project (containing only the files for this one script) if you just to want to produce one exectutable for one script.

      • I don't like the file layout of the result: there's a bin directory for the executables, and a lib directory for the libraries (it doesn't combine the libraries into a single archive, which is not necessarily a bad thing). The exe file is burried in the bin directory.

        That may be the custom in Linux Land, but people using Windows expect the executable to be in the root directory of the location of the app. If you plan to be able to run executables without installation, the root is the most sensible location, IMO.

      • The packer renames the DLLs while copying to their new location, which isn't a bad idea in itself: I've had the experience in Win95 (loooong time ago) that it was simply impossible to load 2 different executables (and DLLs, which are executables too) with the same name, at the same time.

        I think that is the reason for the need of for projects, so different executables can reuse the same renamed DLLS.

        What isn't so nice is the opaqueness of the names, and the lack of information of which DLL got renamed to what. Maybe the info is there, but I haven't seen it.

        The ZIP packager packages a ZIP, file, which includes simply everything that's in its build directory. That includes files that may have been generated by the script itself in a test run. And I've got the impression it may contain quite a bit more files than needed.

      But, all in all, this doesn't look like a bad packager. Quite the contrary.

      • From what I have experienced, the developer(s) of Cava are very receptive to feedback. I would pass on your list to them: [mailto]

        I believe the renaming of DLLs and library files is part of the "source code hiding" effort. I could be wrong for the motiviation behind the renaming, though.

        If you browse the list of "Scanned Modules" and double click one, there is a Packaged Location option which you can change to include modules in a "Standard @INC Folder" (and you can save this as a global de

      • 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 r