Content-type: text/html Manpage of gmkpack

gmkpack

Section: User Commands (1)
Index Return to Main Contents
 

NAME

gmkpack - Maker of packs and scripts for compilation

 

SYNOPSIS

gmkpack -r release [ -a ] [ -b branch ] -u target-pack ]
[ -v reference-pack-version ] [ -n local-pack-version ]
[ -l compiler-label ] [ -o compiling-flag ] [ -V ] [ -m ]
[ -f rootpack ] [ -h homepack ] [ -s ]
[ -p program1[,program2]...[,programN] | listname | ? ]

 

DESCRIPTION

gmkpack is a procedure to create an environment and to compile binaries like Arpege, Aladin, ODB, etc.
While it is similar to a make, it has been written in order to support specific features of the arpege/aladin system (like the so-called "duplicated routines") that a make could not handle.
gmkpack aims to be a user-friendly arpege/aladin-oriented procedure, providing the user with all the links to object libraries and source codes needed to build an executable in a consistent way.

Prior to using gmkpack one should be aware of a few definitions:

Pack

To compile one should copy the compilable source files and possibly other various files in a directory.
This directory is named a "pack".
A pack is a directory containing specific subdirectories and files that will all be created by running gmkpack. Below this directory, source code can be compiled, object libraries resulting from the compilation are built and executables can be made from this libraries and others.
The use of arpege/aladin is made complicated by the need of various "include" files, modules, libraries and sometimes a pre-compiler (for odb) to achieve an executable. gmkpack takes care and provides all this environment in a consistent way. This consistency is ensured by the definition of the reference release, the reference branch name and its version, the compilation mode and the compiler version (these parameters will be described below). More generally, we can try to define a pack as follows:
A pack is a consistent ensemble of source files, libraries and executables related to arpege/aladin.
gmkpack is used for two operations:
+ First : to create a "pack".
+ Second : to generate a script to compile, build object libraries and/or make binaries, using the corresponding pack.
Note that both operations can be performed at once.
gmkpack administrator
A gmkpack administrator is a user who has installed gmkpack in his home directory for a private use or a shared use with other users.
Anyone can be his own gmkpack manager, but usually the gmkpack manager is a an administrator user.
Pack administrator
A pack administrator is a user who has created packs to be used by other users as bases for developments.
Anyone can be his own pack administrator, but usually the pack administrator is the user in charge with the code management.
Main pack
A pack which does not lay upon any existing pack. Such packs could be made by pack administrators only.
Reference pack
A pack upon which one can make another pack. Main packs are obviously reference packs.
Target pack
A pack laying upon an existing reference pack.

 

OPTIONS

-r release
Reference release. This option is mandatory.
For user packs, the already existing releases made by the pack administrator can be obtained by the command rlspack.
For main packs, it should be a string of digits.
-a
To build a main pack and/or a script for a main pack. The mechanism of gmkpack is slightly different for main packs since it has no pack to refer to.
Note that the options -a and (-u,-v) are exclusive.
-b branch
The branch name of the reference pack. It can be a string of any characters except dot (".") and slash ("/"). Default is "main" (for main pack).
-u target-pack
For a user pack, it is the name of the target pack. Since such a target pack can be a subdirectory of a directory of packs, the target pack name may contain a slash ("/").
If not supplied the default name will be the same as the reference pack.
For a reference pack (when the user is administrator), it is the branch name of the target pack. In this case this option is mandatory.
Note that options -u and -a are exclusive.
-v reference-pack-version
Version number of the reference pack. It should be a string of exactly two digits. If omitted, it will be self-computed as the highest existing version number for the selected branch and release.
Note that options -v and -a are exclusive.
-n local-pack-version
Version number of the target pack. This option works only for reference packs (when the user is administrator). It should be either a string of exactly two digits, or the string '++' ; in this case it will be self-computed as the highest existing version number for the selected branch and release, incremented with 1. If omitted, it will be self-computed as the highest existing version number for the selected branch and release.
-l compiler-label
Reference compiler version. More exactly, it is the internal stamp of the configuration file used. The possible values are given by the command optionspack. There is no default value unless the environment variable GMKFILE is set.
-o compiling-flag
Compiler options family. More exactly, it is the extension of the configuration file used. The possible values are given by the command optionspack. The default value is 'x'.
-V
Displays the version of gmkpack. This option is exclusive.
-m
Quiet mode. Enables to make a compilation script without making a pack. This option as been used for debugging only.
-f rootpack
Rootpack directory (absolute path). The default value is ROOTPACK, or $HOME/rootpack if ROOTPACK is not set.
-h homepack
Homepack directory (absolute path). The default value is HOMEPACK, or $HOME/pack if HOMEPACK is not set.
-s
To make a separate script for building the precompilers provided as source code.
This option is rather used for debugging purpose, since the current compilation script is able to handle as well the compilation of the precompilers prior to the actual source code compilation.
As the precompilers are built only inside main packs, this option can be used only with the option -a .
-p program1[,program2]...[,programN] | listname | ?
The list of program to be built, or the name of a list of programs, or the character "?" to build as many executables as possible.
The list of the possible programs, and the possible lists and what programs they contain can be obtain with the command progpack.

 

ENVIRONNEMENT

ROOTPACK
The directory of packs made by the packs administrator (absolute path). Its value should be given by the pack administrator. The default value is $HOME/rootpack
HOMEPACK
The directory of packs made by the user (absolute path). The default value is $HOME/pack
ROOTBIN
The root directory for executables of all reference packs. It enables to store executables in another disk space (possibly larger or semi-permanent).
More exactly the directory $ROOTPACK/<packname>/bin where the executables are stored is a symbolic link to the directory $ROOTBIN/<packname>/bin
HOMEBIN
The root directory for executables of all user packs. It enables to store executables in another disk space (possibly larger or semi-permanent).
More exactly the directory $HOMEPACK/<packname>/bin where the executables are stored is a symbolic link to the directory $HOMEBIN/<packname>/bin
GMKTMP

A temporary directory. For optimal performance, it is recommended to use a local disk space.
GMKFILE
The basename of the configuration file used to run gmkpack. It contains all the variables needed to configure the usage of this command.
For developers, its value should be provided by the gmkpack administrator. If not defined, the use of the option -l of gmkpack is mandatory. Use the command optionspack to get the list of existing configurations.
GMK_OPT
The extension name of the configuration file used to run gmkpack. The default value is 'x'. Use the command optionspack to get the list of existing options.
GMK_ALIASES
If set to any string, whenever a user creates a new pack, gmkpack will add the name of this new pack as an alias in the shell rc file to change directory to this new pack directory at once. Symetrically, rmpack will remove this alias.
GMK_ENABLE_OBJ_RENAME
If set to any string, at linking time gmkpack will rename object files containing a unique symbol so that they will reflect the name of the symbol inside. In certain cases it could be worth setting this variable, but it will slow down the linking step. If this variable can solve a linking problem, you should better try and change the source code !
GMK_IMPORT_PLUGIN
The external script (plug-in) run by gmkpack to import source code while creating a main pack.
Such a script can be written by packs administrators. It works only with reference packs.
GMK_SUPPORT
The directory of support files to run gmkpack (wrappers, configuration files, external scripts).

PACK_PREFIX
The prefix of pack names.
PACK_EXT
The suffix of pack names.

GMK_IGNORE_MULTINAME
export this variable to any non-empty string to prevent gmkpack from aborting when more than one symbol of the same name is found inside a library (main entries are ignored anyway).

GMK_INTFBMODULE_LIB
export this variable to any non-empty string to make gmkpack fill the "unsatisfied reference" archive library with object files resulting from the compilation of autogenerated interfaces encapsulated inside a module. This may be needed to achieve linking edition with certain compilers.

GMK_USER_PACKNAME_STYLE
Style used to construct the user pack names.
If not set, the default is equivalent to :

  "GMK_USER_PACKNAME_STYLE=\${RELATIVE_TARGET_PACK}"
(NB : The backslashes are important !)
The following variables can be used to build a more complex name :
   RELEASE_NUMBER       : reference release number
   RELEASE              : reference release, including the prefix if any
   BRANCH               : reference branch name
   LATEST               : reference branch version
   RELATIVE_TARGET_PACK : user pack short name
   LIBFRT               : compiler stamp
   LIBOPT               : compiler options stamp
   PACK_EXT             : suffix
Examples :

   - Sort packs in one directory per release :
GMK_USER_PACKNAME_STYLE=\${RELEASE_NUMBER}/\${RELATIVE_TARGET_PACK}

   - Extensive information on name :
GMK_USER_PACKNAME_STYLE=\${RELEASE}_\${BRANCH}.\${LATEST}%\${RELATIVE_TARGET_PACK}.\${LIBFRT}.\${LIBOPT}\${PACK_EXT}

   - Paste the root pack name after the user pack name :
GMK_USER_PACKNAME_STYLE=\${RELATIVE_TARGET_PACK}@\${RELEASE}_\${BRANCH}.\${LATEST}.\${LIBFRT}.\${LIBOPT}\${PACK_EXT}

GMKROOT
The directory where gmkpack is installed.

 

EXAMPLES

The following command builds an empty reference pack from scratch, where the release number is 12 and with a script to compile, build archive object libraries, but without making executables :

(. berootpack)
gmkpack -a -r 12

The following command builds an empty reference pack named 'bugfix' on top of the main pack defined above, together with a script to compile and make the executables ARPEGE, ALADIN and AROME (note that this operation cannot be perfomed before the total achievement of the reference pack above) :

(. berootpack)
gmkpack -r 12 -u bugfix -p arpege,aladin,arome

The following command builds a user pack named 'mymods' on top of the pack 'bugfix' defined above, together with a script to compile and make all possible executables :

(. behomepack)
gmkpack -r 12 -u mymods -b bugfix -p ?

 

FILES

$GMK_SUPPORT/arch/
Directory containing the configuration files which can be used by gmkpack (compilers, compilers options mainly).
$HOME/.gmkpack/arch/
The user-private directory where to add more configuration files for gmkpack
$GMK_SUPPORT/wrapper/
Directory containing wrappers to compilers or such commands, to be developped or customized be the administrator.
$GMK_SUPPORT/bin/
Directory containing miscellaneous scripts, like plugins, to be developped or customized be the administrator.
$GMKROOT/link/*
The directory of configuration files specific for each possible executable.
$GMKROOT/link/*/entry
File containing the name of the entry point. It can be a single object filename, or a list of object filename (which will be loaded ahead). Wild characters are allowed. Non-existent object filenames are allowed.
$GMKROOT/link/*/projlist
File containing the list of projects (and thus user libraries) needed to link the executable. The projects are sorted from top to bottom like the subsequent user libraries should be linked (from first to last), before the system libraries. Non-existent projects are allowed.
$GMKROOT/link/*/dummylist
File containing the list of dummy projects (and thus dummy user libraries) needed to link the executable. The dummy projects are sorted from top to bottom like the subsequent user libraries should be linked (from first to last), before the system libraries. Non-existent projects are allowed.
$GMKROOT/link/*/ldflags
File containing on the first line the name of the loader (as a configuration variable name), and on the second line the loading flags sequence (as a configuration variable name).
$GMKROOT/link/*/system_libs
File containing the list of system libraries (as configuration variables names) needed to link the executable. The libraries are sorted from top to bottom like they should be linked (from first to last), after the user libraries.
$GMKROOT/link/*/excluded_libs/*
For each project if present: the list of the stamps corresponding to the sub-libraries to be excluded while linking.
$GMKROOT/link/*/blacklist
File containing the name of the blacklist file used at linking time. If no blacklist file is needed, it can be an empty file.
$HOME/.gmkpack/link/*
The user-private directory where to add configuration files for new executables.
$GMKROOT/intfb/*
For each project if present: the release since when the auto-generated interface blocks have been used.
$GMKROOT/libs/*/*
For each project if present ($GMKROOT/libs/*): the sub-libraries stamps as files containing the list of the sub-directories serving each sub-library.
$GMKROOT/home/exenames
The file containing the name of each executable. To be used as a starting point for customization.

 

AUTHOR

Ryad El Khatib <ryad.elkhatib@meteo.fr>

 

SEE ALSO

admpack(1), behomepack(1), berootpack(1), brushpack(1), envpack(1), cleanpack(1), genpack(1), gmkfilemaker(1), idotpack(1), lockpack(1), logpack(1), lspack(1), mpsh(1), optionspack(1), progpack(1), readpack(1), resetpack(1), rlspack(1), rmpack(1), scanpack(1), showpack(1), usrpack(1), vimpack(1).


 

Index

NAME
SYNOPSIS
DESCRIPTION
OPTIONS
ENVIRONNEMENT
EXAMPLES
FILES
AUTHOR
SEE ALSO

This document was created by man2html, using the manual pages.
Time: 14:15:33 GMT, June 17, 2014