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:
# 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).
Name=LabPython
# 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.
Version=2.7
# 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.
Release=1
# 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.
License=LGPL
# 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.
Icon=labpython.png
# 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
Vendor=OpenG.org
# 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.
URL=http://labpython.sf.net
# 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 <rolf.kalbermatter@citeng.com>
# 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.
AutoReqProv=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.
#Exclude_LabVIEW_Version=""
#Exclude_LabVIEW_System=""
#Exclude_OS=""
#Exclude_Arch=""
# 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
#Exclusive_Arch=ix86
#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.
#PreBuild=""
# 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.
#PostBuild=""
# 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
#PreInstall=""
# 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
#PostInstall=""
# 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
#PreUninstall=""
# 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
#PostUninstall=""
# 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.
#Verify=""
#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.
DocGroups=0,1
#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 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.
#Exclude_LabVIEW_Version=""
#Exclude_LabVIEW_System=""
#Exclude_OS=""
#Exclude_Arch=""
#Exclusive_LabVIEW_Version=6.0, 6.1
#Exclusive_LabVIEW_System=Development System, Student Edition
#Exclusive_OS=Windows 95/NT, Mac OS, Linux
#Exclusive_Arch=ix86
#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