 News |
FAQ
|
| Search
|
Home
|
| Getting Started | Documentation | Glish | Learn More | Programming | Contact Us |
|
| Version 1.9 Build 1556 |
|
Retrieve AIPS++ source code updates.
inhale [-b] [-c|-m] [-D] [-d] [-l] [-n] [-P] [-R NAME] [-r#] [-w#] [-cvsup data|docs|all] [binary]
inhale is a part of the AIPS++ code distribution system. It allows
participating AIPS++ code development sites to maintain a slave copy of
the master RCS repository which is no more than 12 hours out-of-date
(see exhale (p![[*]](../../gif/latex2html/cross_ref_motif.gif)
)).
inhale fetches the compressed tar files needed to update a
consortium site's copy of the AIPS++ RCS repositories from the
/pub/master area on the master AIPS++ host aips2.nrao.edu.
After installing the updates, inhale invokes sneeze (p) to rebuild
the system and documentation. The rebuild may be done serially or in parallel
for any number of AIPS++architectures on various hosts.
The update files are of three types (see exhale (p)):
inhale compares version information stored in the /pub/master/VERSION file on the master machine with that in $AIPSLAVE/VERSION on the local machine to determine which files need to be fetched.
If the $AIPSLAVE/VERSION file does not exist, or if the major version number stored therein is less than that of /pub/master/VERSION, inhale fetches the latest base release. If the -c option was specified, inhale will fetch the cumulative update file. Otherwise, as many of the incremental update files will be fetched as are needed to bring the system up-to-date. If there are insufficient of these stored in /pub/master, then inhale resorts to a cumulative update.
If an update contains the RCS version file for ax_master then it will be applied to the slave and code areas before the update is installed. This may happen several times for a multi-increment update. Cumulative updates always contain ax_master which inhale applies in cumulative mode.
If the major version number recorded in /pub/master/VERSION is greater
than that recorded in $AIPSLAVE/VERSION, or if
$AIPSLAVE/VERSION does not exist, then inhale does a ``base
installation''. In this mode it fetches only the base release file and before
installing it deletes any existing slave and code directories. After
installing it, and if not contra-indicated by the
inhale.base.slave.preserve and inhale.base.slave.preserve
resources, inhale preserves a copy of the slave and code directories in
$AIPSROOT/base-MM/..., where MM is the major version number of
the new base release. inhale then invokes sneeze (p) in base mode.
After doing a base installation, inhale reinvokes itself if necessary to bring the minor version number up-to-date.
inhale maintains the LOGFILE files in $AIPSLAVE and
$AIPSCODE. These record the version, time of completion, and mode of
the last slave and code updates (see avers (p)).
).
). Note that even if documentation compilation is
defeated via the DOCSYS variable in makedefs (p) (see
makedefs (p)) this option may still be useful in preventing
docsys from being recorded in the LOGFILE entry for the
rebuild.
)).
) in cumulative mode. This is useful for
minimizing file transfer times when performing cumulative style
updates over slow network links.
inhale always ignores $HOME/.aipsrc (see getrc (p)).
General resources.
The following resources used by inhale should be defined in $AIPSROOT/.aipsrc.
)) then
preserve the slave repository when a new base release is installed.
) to rebuild AIPS++ for architectures which differ from
that of the host on which inhale is executing. An architecture
extension (see (aipsinit (p)) may be specified by appending it to the
hostname with an intervening colon, i.e. <hostname>:<aips_ext>.
The aips_ext is explicitly permitted to be null or set to
"_" to signal the host's default architecture. The inhale
host's name will be ignored if included in the list (unless an extension is
specified).
) on remote systems. Defaults to
rsh. ssh, the ``secure shell,'' is one possible
alternative.
) or have met whatever other criteria is deemed
suitable.
) on multiple client machines of different
architectures then those clients will be updated to the most
recently-blessed version for the inhale host's architecture,
not their own.
) to rebuild the AIPS++
system which includes the inhale executable it must take precautions
to avoid overwriting itself. It does so by copying itself to inhale-
and then exec'ing this.
Status return values correspond to the various phases of the operation
0: success
1: initialization error
2: initial ftp error
3: main ftp error
4: error extracting or installing the new RCS files
5: error checking out the new code
6: error rebuilding the system
The following aips2mgr cron job entry runs inhale at 2300 each night performing a cumulative update on Saturday evening, and incremental updates on all other evenings:
# Update the AIPS++ slave directories, incremental Sun-Fri, cumulative Sat.
00 23 * * 0-5 (. $HOME/.profile ; inhale) 2>&1 | \
mail -s "Epping inhale" aips2-inhale@nrao.edu
00 23 * * 6 (. $HOME/.profile ; inhale -c) 2>&1 | \
mail -s "Epping inhale -c" aips2-inhale@nrao.edu
(Note that all cron entries must be one-liners but they are broken here for clarity.) The inhale log is emailed to the aips2-inhale exploder which allows the code distribution system to be monitored. An alternative method is to forward all of aips2mgr's mail via the $AIPSROOT/.forward file, or as a mail alias.
The unix manual page for tar(1).
The unix manual page for cron(1).
The unix manual page for rsh(1).
The unix manual page for ssh(1).
AIPS++ variable names (§1.2).
Section §1.4, AIPS++ accounts and groups.
affirm (p), get the Boolean value of a set of arguments.
avers (p), AIPS++ version report utility.
ax (p), AIPS++ code deletion utility.
exhale (p), AIPS++ code export utility.
getrc (p), query AIPS++ resource database.
makefiles (p), GNU makefiles used to rebuild AIPS++.
sneeze (p), AIPS++ system rebuild utility.
testsuite (p), maintain the most recent good cumulative update.
Original: 1992/04/08 by Mark Calabretta, ATNF.