Package Spec File

The package spec file is a normal ini style file and contains all the information necessary for the package to be built on the developer's system and to correctly install the on the target computer. The file contains a global section with general information about the project, supported platforms and more. For each target location (directory) an additional file group section is added which specifies the target directory, the overwrite mode, supported platforms if different from the general supported plattforms, and the list of files belonging to the this group.
The file would look similar to this:

FIle Sections

[Package Name]

# The Package Name section is used by OGPM to produce the package's final name.
# Since the name is always in the format: <name>-<version>-<release>

# The name key is used to define the name of the software being packaged. In most (if not all) cases, the name used for a package should be identical in spelling and case to the software being packaged. The name cannot contain any whitespace: If it does, OGPM will only use the first part of the name (up to the first space).

# The version key defines the version of the software being packaged. The version specified should be as close as possible to the format of the original software's version. In most cases, there should be no problem specifying the version just as the software's original developer did. However, there is a restriction. There can be no dashes in the version. If you forget, OGPM will remind you (error message). Spaces in the version will also cause problems, in that anything after the first space will be ignored by OGPM. Bottom line: Stick with alphanumeric characters and periods, and you'll never have to worry about it.

# The release key can be thought of as the package's version. The release is traditionally an integer. For example, when a specific piece of software at a particular version is first packaged, the release should be "1". If it is necessary to repackage that software at the same version, the release should be incremented. When a new version of the software becomes available, the release should drop back to "1" when it is first packaged. Note that we used the word "traditionally", above. The only hard and fast restriction to the release format is that there can be no dashes in it. Be aware that if you buck tradition, your users may not understand what your release means. It is up to the package builder to determine which build represents a new release and to update the release manually.


# The Description section provides information primarily for people who want to know a bit more about the package, and who produced it. They are part of the package file.

# The Description key is used to provide an in-depth description of the packaged software. The description should be several sentences describing, to an uninformed user, what the software does.
Description="LabPython is freely available under the LGPL - you can copy it, modify the source code, or even sell it, as long as you make any changes to the source code available to the public."

# The Summary key is used to define a one-line description of the packaged software. Unlike description, summary is restricted to one line. OGPM uses it when a succinct description of the package is needed.
Summary=Python scripting interface

# The Licesnse key is used to define the copyright terms applicable to the software being packaged. In many cases, this might be nothing more than "LGPL", for software distributed under the terms of the GNU Lesser General Public License, or something similar.

# The Copyright key is used to define the copyright holders.
Copyright=2002 Rolf Kalbermatter, Jim Kring

# The Distribution Key is used to define a group of packages, of which this package is a part.
Distribution=OpenG Toolkit

# The Icon key is used to name a file containing an icon representing the packaged software. The file may be in either JPEG, GIF, or PNG format. The background of the icon should be transparent. The icon is normally used by graphically-oriented front ends to OGPM. The icon, is stored in the package file and retained in OGPM's database after the package is installed.

# The vendor Key is used to define the name of the entity that is responsible for packaging the software. Normally, this would be the name of an organization

# The URL key is used to define a Uniform Resource Locator that can be used to obtain additional information about the packaged software. The data is written into OGPM's database when the package is installed.

# The Packager key is used to hold the name and contact information for the person or persons who built the package. Normally, this would be the person that actually built the package, or in a larger organization, a public relations contact. In either case, contact information such as an e-mail address or phone number should be included, so customers can send either money or hate mail, depending on their satisfaction with the packaged software.
Packager=Rolf Kalbermatter <>


# OGPM ensures that if a package is installed, the system environment has everything the package requires in order to operate properly. Likewise, when an installed package is erased OGPM can make sure no other package relies on the package being erased. This dependency capability can be very helpful when endusers install and erase packages on their own. It makes it more difficult for them to paint themselves into a corner, package-wise. However, in order for OGPM to be able to take more than basic dependency information into account, the package builder must add the appropriate dependency information to the package.

# The Requires key is used to alert OGPM to the fact that the package needs to have certain capabilities available in order to operate properly. These capabilities refer to the name of another package. When the requires key references a package name, version comparisons may also be included by following the package name with <, >, =, >=, or <=, and a version specification. To get even more specific, a package's release may be included as well.
#Requires="bar >= 2.7-4; baz = 2.1-1"

# The conflicts key is the logical complement to the requires key. The requires key is used to specify what packages must be present in order for the current package to operate properly. The conflicts key is used to specify what packages cannot be installed if the current package is to operate properly. The conflicts key has the same format as the requires key; namely, the key is followed by a package name.
#Conflicts="foo <= 2.7"

# The AutoReqProv key is used to control the automatic dependency processing performed when the package is being built. Normally, as each package is built, all VIs being packaged are analyzed to determine their package requirements. These requirements are automatically added to the package's requirements. By doing this, OGPM reduces the need for package builders to manually add dependency information to their packages. However, there are times when OGPM's automatic dependency processing may not be desirable. In those cases the autoreqprov key can be used to disable automatic dependency processing. OGPM defaults to performing automatic dependency processing. To disable automatic dependency processing, set this key to FALSE.



# The exclude keys directs OGPM to ensure that the package does not attempt to build on the excluded LabVIEW Version/Systems, Platforms, or OSes. The reasons for preventing a package from building on a certain version might include: (1) The software has not yet been ported to the excluded LabVIEW version. (2) The software would serve no purpose on the excluded LabVIEW version. An example of the first case might be that the software was designed based on the assumption that features of LabVIEW are available. In the second case, software that depended on or are manipulated by low-level features of a given LabVIEW version, should be excluded from building on a different version. One or more LabVIEW versions may be specified after the ExcludeVersion tag, separated by either spaces or commas. Here is an example: ExcludeVersion=<6.0. In this example, OGPM would not attempt to build the package on any version of LabVIEW less than 6.0. The package would build on any other versions, however. If a build is attempted on an excluded version, an error will result. Note that if your goal is to ensure that a package will only build on one version, then you should use the ExclusiveVersion tag.





# The exclusive keys are used to direct OGPM to ensure the package is only built on the specified LabVIEW Version/Systems, Platforms, or OSes. The reasons for this are similar to those mentioned in the section on the ExcludeVersion tag above. However, the ExclusiveVersion tag is useful when the package builder needs to ensure that only the specified LabVIEW versions will build the package. This tag ensures that no future versions will mistakenly attempt to build the package. The syntax of the exclusive keys is identical to that of exclude keys. Note that if your goal is to ensure that a package will not build on specific LabVIEW versions, then you should use the exclude keys.

#Exclusive_LabVIEW_Version=6.0, 6.1

#Exclusive_LabVIEW_System: A list of LabVIEW systems compatible with this project, default: Development System only
Exclusive_LabVIEW_System=Development System, Student Edition

#Exclusive_OS: All, or a list of any of the enumerations returned by "LabVIEW.TargetOS"
Exclusive_OS=Windows 95/NT, Mac OS, Linux


[Script VIs]

#The relative path from the spec file to the Build-Time Scripts.
Source Dir=""

# This section is where the necessary preparations are made prior to the actual building of the package on the developer's machive. In general, if anything needs to be done to the sources prior to building the software, it needs to happen in the prep section. For example, you may want to do a CVS update, or tag the sources with version information.

# Another "script" VI that can be present is a "script" VI that can clean things up after the build. This script is rarely used, since OGPM normally does a good job of cleaning-up in most build environments.

# This is another "Script VI" that is executed on the target system. The PreInstall "script" VI will run before the package is installed on the target system

# This is another "Script VI" that is executed on the target system. The PostInstall "script" VI will run after the package is installed on the target system

# This is another "Script VI" that is executed on the target system. The PreUninstall "script" VI will run before the package is uninstalled on the target system

# This is another "Script VI" that is executed on the target system. The PostUninstall "script" VI will run after the package is uninstalled on the target system

# This is another "Script VI" that is executed on the target system. It is executed when OGPM verifies the package's proper installation. While OGPM does most of the work verifying packages, this script can be used to verify aspects of the package that are beyond OGPM's capabilities.


#Documentation link for the project documentation. Relative path is contained in archive. http:/ is also possible
Documentation=LabPython Manual.html

#File groups containing the documentation files when the previous path was relative. If the user selects the
#documentation link, these groups are copied to the temp directory and launched from there.

#Where is the root of all relative target dirs, <labview> = LabVIEW root is default. File Groups can specify a
#different starting directory with special keywords: <os> (Win, WinNT, MacOS), <system> (Win/System, Extensions)
#<examples> LabVIEW/Examples, <help> LabVIEW/Help, <menu> LabVIEW/Menu/{current}, etc
Target Dir=<labview>

# The number of File Group sections that follow
Num File Groups=01

[File Group N]

# File groups are files that are are grouped by source and target location, platform dependencies, etc.

# The exclude and exclusive keys in the File Group sections are used to define whether the file group will be installed on the target platform. These follow they same format as the exclude and exclusive keys in the platform dection.




#Exclusive_LabVIEW_Version=6.0, 6.1

#Exclusive_LabVIEW_System=Development System, Student Edition

#Exclusive_OS=Windows 95/NT, Mac OS, Linux


#The relative path from the spec file to the File Group's Source Dir.
Source Dir=string.llb

#If relative path and no target secifier, it is relative to global Target Dir.
Target Dir=resource/script

#Replace Mode: Never, Always, If Newer
Replace Mode=If Newer

#Number of files following
Num Files=3

File 0=LabPython Manual.html
File 1=palette.html
File 2=scriptnode.html