Main Site Contents Up Previous Next

Project Home


Project Details

Product Name

The Product Name is embedded in your executables and accessible at run time using Cava::Packager functions. On Windows it is also written to the executable version information structure.

Vendor

The Vendor details are embedded in your executables and accessible at run time using Cava::Packager functions. On Windows they are also written to the executable version information structure.

Copyright

The Copyright notice is embedded in your executables and accessible at run time using Cava::Packager functions. On Windows it is also written to the executable version information structure.

Trademarks

The Trademarks details are embedded in your executable and accessible at run time using Cava::Packager functions. On Windows they are also written to the executable version information structure.

Comments

The comments are embedded in your executable and accessible at run time using Cava::Packager functions. On Windows they are also written to the executable version information structure.

Version

The four part version is embedded in your executable and accessible at run time using Cava::Packager functions. On Windows the version is also written to the executable version information structure. The fourth and final part of the version string is not editable but is incremented each time a successfull build is completed. The version string is also used when determining the extract directory if the project utilises compression. See the 'Runtime Extract Options' item under 'Build Options' below for further detail.

Project Class Id

The Project Class Id is used during application executable creation and when determining the extract directory if the project utilises compression. See the 'Runtime Extract Options' item under 'Build Options' below for further detail.


Build Options

Default Package Method

Cava Packager can package your Perl code either as plaintext or as masked text where the code is retrieved using a source filter. The choice you make here will be the default for this project. This setting can be overridden before building your project on an individual file or directory tree basis.

Default Package Location

Cava Packager can include your modules and dependencies in one of two ways. Either as part of a Virtual @INC folder where the directory structure is flattened and files cannot be retrieved by their original names or in a Standard @INC folder where the expected directory structure and file naming system is maintained. Some modules search for files by traversing an expected directory structure and the simplest method of packaging these modules in a working state is to preserve the directory structure in a Standard @INC folder. The choice you make here will be the default for this project. This setting can be overridden before building your project on an individual file or directory tree basis.

Absolute Path Rule

Select whether Cava Packager includes scripts or modules that your scanned code or modules use via a 'do' or 'require' statement with an absolute path.

For example, if you have a script named 'c:\myproject\myscripts\runscript.pl' and you call this from your main script with:

do 'c:\myproject\myscripts\runscript.pl';

then you have the option to choose whether Cava Packager should include the file 'runscript.pl' within your package.

Using 'do' or 'require' with an absolute path can have unexpected results. In the above example, if you run your package executable on a machine where a file named 'c:\myproject\myscripts\runscript.pl' exists, then the perl file on the machine will be loaded via 'do'. If the file 'c:\myproject\myscripts\runscript.pl' does not exist, then the packaged version distributed with your executable will be used.

You can avoid these problems simply by not using absolute paths in your code.

For example, if your normal perl code runs from the directory 'c:\myproject' and therefore 'c:\myproject' is always in your code's @INC, then you can simply change your 'do' statement to:

do 'myscripts\runscript.pl';

When packaging, just add 'c:\myproject' to your module search paths. Then your packaged executable will always load the packaged runscript.pl.

You can always override this default within an individual project.

Top Level App Folder

When your application is built, the release files are placed in a pre-determined side by side directory structure. The top level app folder is the name of the folder under which these directories will be placed. For example, a top level app folder of "My App" will produce the following directory structure for a standard uncompressed windows application:

My App
My App\bin
My App\dll
My App\lib
My App\res

In a MacOSX App Bundle, the Top Level App folder will be suffixed with '.app'

Post Build Script

You may specify the path to a Perl script here that will be run after your application build but before any distributables or archives are created. This script is commonly used to add custom directories and content to the build.

The script is run under the Perl you have selected to package your application with. The module Cava::Packager::Release is available so that you can get information about the release.

# postbuildscript ------------------------------------------------

use strict;
use warnings;
use Cava::Packager::Release;

my $release = Cava::Packager::Release->new();

my %releasevals = ();
$releasevals{'Product Name'} = $release->get_product_name;
$releasevals{'Version String'} = $release->get_version_string;
$releasevals{'Version Major'} = $release->get_version_major;
$releasevals{'Version Minor'} = $release->get_version_minor;
$releasevals{'Version Release'} = $release->get_version_release;
$releasevals{'Version Build'} = $release->get_version_build;
$releasevals{'Vendor'} = $release->get_vendor;
$releasevals{'Copyright'} = $release->get_copyright;
$releasevals{'Comments'} = $release->get_comments;
$releasevals{'Trademarks'} = $release->get_trademarks;
$releasevals{'Release Path'} = $release->get_release_path;
$releasevals{'Bin Path'} = $release->get_bin_path;
$releasevals{'Library Path'} = $release->get_dll_path;

print qq($_ = $releasevals{$_}n) for (keys(%releasevals));
1;

#-----------------------------------------------------------------

The accessor get_release_path returns the release folder under which your 'lib' and possibly 'res' folders are placed. This is where you should add any additional custom directories or files. Bin path and DLL path are provided via different accessors as the absolute location of these folders may vary across operating systems and project types.

The permissions you set for any file created by the post build script will be preserved when bundling into an archive or distributable.

If you add additional directories then at run time you can retrieve the location of the packaged 'release path' directory with the Cava Packager utilities function Cava::Packager::GetAppRoot(). Therefore a directory added to $release->get_release_path named 'mypath' would be available within your executable at Cava::Packager::GetAppRoot() . '/mypath'; .

Self Extractor Password

Cava Packager can produce a self extracting zip archive of your release folder. If you wish you may add a password for the wrapped zip file contents. Note that this is just the same as specifying pkzip 'encryption' when compressing files into a zip archive and provides weak encryption with well known methods of extracting the files without needing the password.

Cava Packager stores the password within your project files in plain text.

If you are using the Linux Installer any self extractor password is ALWAYS ignored when creating a self extracting zip.

Virtual Source Loading

From Version 2.0.72 Cava Packager offers a choice of two methods for packaging your masked source code.

The default is the 'Compressed Virtual Source Loader' which is the latest addition to Cava and should provide you with the fastest load times as well as the smallest distributables. Cava Packager itself has a 5mb smaller footprint when this option is used.

The 'Standard Virtual Source Loader' is the Cava masked source loader from version 2.0.70 and below. You may continue to use this source loader if you wish.

Runtime Extract Options

Cava Packager provides the option to package up your Resource Folder in compressed format and extract it at run time.

The files are extracted to a temporary directory when your application starts. The files are not removed when your application exits allowing a faster startup on subsequent executions.

Runtime extraction imposes a time penalty on your application startup so you may choose not to compress your resources. The optimal default and recommended setting for Cava Packager is not to compress any files.

The name of the temporary directory is calculated using a hash of the Product Class Id and the four parts of the Version string. At extract time, your packaged executable will check the temporary extract directory for a version file which contains all four parts of the Version string. If the version has incremented, Cava Packager will re-extract all files. Otherwise, Cava will only update missing files.

The intended usage of this scheme is that each time you create a new version of your application, you will have no issues with version collision and Cava Packager can utilise quick startup execution behaviour after the initial extract on first execution. The final part of the Version string is automatically incremented causing Cava Packager to always use a new extract path for each build of your application.

Diagnostic and Test Options

Cava Packager provides options to distribute diagnostics and tests with your application.

Package Diagnostic Executable with Release.

Within Cava Packager you can run your executables in diagnostic mode. In this mode all output from the executable is visible in a terminal window and you can optionally have the Cava Packager Loader display verbose output which can help in diagnosing problems. This capability is not normally available once the executables are distributed. By checking this option, Cava Packager will create a diagnostic executable that you can distribute with your application. Running your packaged executables via this diagnostic exec will produce the same output as testing within Cava Packager.

Allow loader verbose output in release executables.

If you distribute a diagnostic executable as described above, you can choose whether the Cava Packager Loader verbose output is displayed when your applications are run via the diagnostic executable.

Package Test executable with release.

Cava Packager allows you to build tests that can run against your packaged Modules and scripts. You can also choose to create a special test executable that can run these tests if distributed with your application. If you do this, then all your test scripts and their dependencies will be included within your main package.

See Testing and Diagnosing Problems for further information.


Perl Interpreter

Executable

Select a Perl executable to determine the installation of Perl that you will use to package your scripts. You can check the properties of the selected perl by using:

Display properties of selected Perl

Extra Module Search Paths

When scanning for your script dependencies, Cava Packager will search in the @INC array of the selected Perl executable. You can add additional directories to search here. Additional directories are always searched before directories in the @INC array and in the order specified in this dialog.

Note that by default '.' is not included in any search paths. If you want to search for modules in the same path as your scripts, add the fullpath to the folder as an additional directory to search.

Add a new directory to the search paths.
Remove the selected directory from the search paths.
Move the selected directory UP in the search order.
Move the selected directory DOWN in the search order.


Mac Bundle

If the project is a MacOSX App Bundle the Project Home node contains an additional tab that allows you to set some bundle specific properties.

Bundle Executable

You can package more than one executable in a Bundle project, but one executable must be the default for execution when the user selects the .app application. Select the executable to use as a default here.

Bundle Name

The default Bundle name that appears to the end user is the same as the Top Level App Folder (with the .app suffix removed). You can set an alternative name for the bundle here.

Bundle Icon

You can select a .icns file to use as the icon for your application. Once selected the file is added to your stored icon resources. If you alter or edit the original source file you will have to import the new version into your icon resources and select it.





Contents Up Previous Next


Cava Packager Copyright © 2006-2012 Mark Dootson