Entry Operations

The Entry Operations options from the package configuration level. The options allow new packages to be defined and established package definitions to be modified. Packages can be built directly from the several of the options.

VIEW

View allows you to view the current configuration of a package. Clicking the view button brings up the query portion of the VIEW window shown below.

From this window you select the packge whose definition is to be viewed. Selection is made by clicking on the blank button the right of the PACKAGE label. This brings up a list of all packages being managed. The selection is made from this list. Each package in the list has in parenthesis after it an abbreviation indicating its base directory directory. Selecting a package, in this case PkgMgr, adds the current package configuraton to the window. This is shown in the figure below.

NEW

New begins the process of creating a new package definition. Clicking on the NEW button brings up the blank package configuration sheet shown below.

The various options in the package configuration are described in some detail below. Not all the options may be applicable to the package being defined. Those not applicable can be left unset. It should be noted that any compilation, linkage, or release commands are assumed to be handled through a Makefile.

PACKAGE NAME

This is a required field. It contains the name of the package being defined. You can make up any name for the package you wish as long as it does not match the name of any other defined package in the UDF package archive.

PACKAGE REVISION

This is a required field. It is the current package revision number which must be of the format MjRV.MnRVrRN where MjRV is the package major version number, MnRV is the package minor version number, and RN is the package release number. An example would be 3.1r5.

PACKAGE BASE DIRECTORY

This is a required field. There are 6 UDF base directory definitions and the package must be assigned to one of these. The base directories are:

BASE	DESCRIPTION
UDF_HOME	Holds the core UDF packages. This directory should only hold packages maintained by UDF developers and should not be used to house externally developed packages.
GPH_HOME	Holds the core graphics packages. This directory should only hold packages maintained by GPH developers and should not be used to house externally developed packages.
UDFTOOL_HOME	Base directory of most of the UDF administration packages as well a applications which can be used across multiple UDF set definitions such as ADump or UDFplot.
TCLTOOLS_HOME	Use this base directory for any TCL based applications. Many of these operate only on specific UDF sets.
IDLTOOLS_HOME	Use this base directory for any IDL based applications. Many of these operate only on specific UDF sets.
UDFDOC_HOME	Use this base directory for any UDF html based documentation or manuals. This includes documentation associated with any of the developed applications

To select the Base Directory click on the initially blank option bar and select one of the options.

HOME DIRECTORY

This is a required field. The package home directory is the directory set up in the package install under the package base directory where all the package files are placed. The package home directory can be set multiple directories below the base directory by listing all the directories in the tree. Each directory is separated by a space. So entering A B C for the field sets the home directory as BASE/A/B/C where BASE is the Base Directory from the BASE DIRECTORY field.

SUBDIRECTORIES

This is an optional field. It contains a list of any subdirectories needed to be set up under the home directory. Only one layer of subdirectories is supported (no directories under subdirectories). Multiple subdirectory entries are entered space separated.

NEEDS COMPILING

If the package has elements which need to be compiled this this option needs to be changed from NO to either YES or YES TO SHARED LIBRARY. YES will produce any libraries generated to be either shared or static libraries depending on the system compile options found in the MakeRc file. YES TO SHARED LIBRARY will force all libraries to be produced as shared libraries. This is used generally when the resultant library is required to be a shared library such as an IDL DLM library.

LINK COMMAND

This is an optional field. If the package needs to be linked together to produce one or more executables then this lines contains the input to make to produce the executables. Multiple inputs are allowed and are space separated.

NEEDS TO RELEASE

If the package needs to release (move) any files to other directories once the compiling and linking phases have been completed then this field should be set to YES, otherwise leave it as NO.

FILES MOVED TO bin

This is an optional field. If there are any files in the package which need to be moved to the bin directory which exists under the package base directory then list them. If there are more than one then they are separated by spaces. Note that any files which might have been moved into the bin directory as the result of a release in the Makefile should not be added here.

NEEDS pkg_mkIndex

If the package contains Tcl/Tk based code which needs to have the pkg_mkIndex utility run on them to to create indexed files then set this option to YES otherwise leave it set to NO

PURGE OLD INSTALL

Leave set as YES if you want any older versions of the package to be purged prior in installing the current version, set to NO otherwise. Purging older versions makes sure that all stale files are removed in the upgrade to the newer version.

INSTALL IF EXISTS

Leave set as YES if you want to replace older versions of the package with the newer version, set to NO otherwise. Setting to NO wil mean that the package can only be installed once on the system.

USES AUpkgSpecial

Most packages will leave this set at NO. AUpkgSpecial is a package specific Tcl procedure which allows for install steps not found in the generic install scripts. If the package you are setting up does not have a section built into AUpkgSpecial then it doesn't need it. If your package may need added steps contact the developers to have those added to AUpkgSpecial.

WINDOWS EXTENSIONS

If any executables in your package need to have extensions added to them to make them recognized as executable under WINDOWS then add them here. There should be one extension per entry in the FILES MOVED TO bin entry. In general on WINDOWS you need to add tcl as an extension for any Tcl-based executable. If there are multiple executables, some of which does not need to have an extension added, then set those extension to ""

ENVIRONMENT VARIABLES

This is a space separated list of environment varaibles which need to be set for the package to be installed and usable. At the least, the environment varaible which points to the package base directory should listed here. Most if not all of the required environment variables will be a subset of the standard UDF environment variables.

FILE MANIFEST

This is a space separated list of all files which are to be included in the package. All the files listed must exist under the package home directory or in directories below them. If the package is maintained in a directory other than the listed Home directory then a link between that directory and the Home directory needs to be created. You can add all files of a specific extension by using the * wild card followed by the extension. For example to include all the .c files in the home directory use *.c. You can include an entire subdirectory by including the subdirectory name with a colon appended to it. To include the subdirectory SubFiles use SubFiles:. To include only a specified file from the subdirectory, add it the colon.

DEPENDENCY LIST

If the package depends on other packages being installed then those packages are listed there. Individual packages are listed in the format H,PKG,R where H is an abbreviation representing the package base directory (see table below) and PKG is the package name, and R is an optional revision value of the same format used in specifying the package revision. If the revision number is not include the preceeding , is dropped.

ABBREVIATION	BASE
U	UDF_HOME
G	GPH_HOME
A	UDFTOOL_HOME
T	TCLTOOLS_HOME
I	IDLTOOLS_HOME
D	UDFDOC_HOME

In addition to naming packages individually, the entire UDF core package set can be added to the dependency list as UDFCORE and the entire graphics core package set as GPHCORE. Any

USE SPECIAL INSTALLER

If this package has a special install procedure build for it then put the name of the procedure here. There are two special installers currently contained within the UDFLibrarian package. There are AUudftoidlInstall and AUtclInstall. The first is specific to the installation of the UDFTOIDL package. The second should be used for any Tcl based package which has associated C-code backing it. The C-backing must be in a subdirectory named C-Code. The procedure will do a normal install and then compile the C-backing code.

RECOMPILE WHEN UPDATING

This is currently an unimplemented option.

FILE MANIFEST (WINDOWS)

This is an optional field. If the package provides a WINDOWS binary install of any executables and libraries then this field is a list of the required files. NOTE: Windows binary installs only occur when installing C-Based code for which source compiles are not supported.

DEPENDECY LIST (WINDOWS)

This is an optional field. If the package provides a WINDOWS binary install then this is a list of any necessary packages which must be present for the install to proceed and the application to execute.

Once the package configuration has been filled in you should click on the CHECK button. This checks for several of the more common problems which occur in the package definition. An example check for a definition of the UDFLibrarian package is shown below.

Once all the errors reported in the package check are resolved you can either SAVE the definition or SAVE/BUILD the definition. A saved definition is placed in the package database file Pkg.db which is located in the directory $UDFTOOL_HOME/ConFigs. A built package is put into the PKGS directory which is located under the package base directory.

EDIT

The EDIT function is very similar to the NEW function except here you select an already defined package and are allowed to modify its definition. It is used most often to either complete an incomplete package definition or to bump up the version number of an updated package.

Clicking the EDIT button brings up the window shown below.

Clicking on the blank option bar brings up the list of packages which are currently found in the local package database. Selecting on of these fills in the remaining fields.

Once you have updated the necessary fields you should click on CHECK to see if there are any problems with the definition and then either SAVE or SAVE/BUILD the definition. These options are discussed more fully under the NEW function above.

DELETE

Delete allows you to delete any of the packges currently saved in the local package database. Clicking the delete button brings up the query portion of the DELETE window shown below.

From this window you select which packge to delete. Selection is made by clicking on the blank button the right of the PACKAGE label. This brings up a list of all packages in the local database from which the selection is made. Each package in the list has in parenthesis after it an abbreviation indicating its base directory. Selecting a package, in this case UDFPlot documentation package, adds the current package configuraton to the window. This is shown in the figure below. To delete the package then click on the DELETE button at the upper right.

MULTIPLE DELETES

Multiple Deletes allows you to delete any or all of the packges in the local package database. Clicking the multiple builds button brings up the query portion of the MULTIPLE DELETE window shown below.

This is identical in format to the Delete selection window. From this window you select to see ALL of the packges being managed or only packages under a particular package base directory. Selection is made by clicking on the blank button the right of the PACKAGE HOME label. The figure below shows the results of selecting to see the packages defined under the TCLTOOLS_HOME directory. Each package is listed with an associated check box. Check all of the packages you wish to delete and then click on the DELETE button at the upper right to remove them.