INSTALL_PACKAGE
http://www.cs.bham.ac.uk/research/poplog/tools/install_package/install_package.txt
$local/ftp/tools/install_package/install_package.txt
Aaron Sloman
http://www.cs.bham.ac.uk/~axs/
3 Jan 2005


The shell script install_package that is included with the bham linux
poplog package has been changed

 a. to use bash not csh

 b. to allow arguments in either the form 'foo' or 'foo.tar.gz'

 c. to allow more than one argument

The new version is available here
    http://www.cs.bham.ac.uk/research/poplog/com/install_package

It assumes the following conventions for extensions to poplog. These
have been discussed previously. Not everyone likes them, but I have
not yet seen a workable and preferable alternative.

1.  A poplog local directory is $poplocal/local (abbreviated to $local)

2.  This should normally be outside the $usepop tree so that one
    can remove an old $usepop tree and install a new one (e.g. newer
    version of poplog), without losing local extensions.

3.  The directory $local may contain the following general-purpose
    subdirectories replicating a subset of the directories in
    $usepop/pop/ (only those marked with an asterisk are currently
    installed by default in $local in the bham linux poplog package):

        auto    *
        com     *
        data
        doc     *
        help    *
        include
        lib     *
        lisp
        plog
        pml
        ref     *
        setup   *
        teach   *

    Notes:
        The $local/com directory contains shell scripts for building
        bham saved images, making indexes, etc.

        The $local/setup directory includes a default Poplib directory,
        man directories, a userguide.html file, and a bin directory with
        shell scripts for running poplog or setting up environment
        variables. (The shell scripts are now created by the
        installation scripts, so that $usepop is defined correctly for
        the installation.)

4.  In addition, 'package' directories may be installed in $local.

    Packages with collections of auto, lib, help, etc. files should
    not scatter their files around the general purpose directories
    listed above (as used to be done at Sussex) since files from
    one package can clobber others, and this makes it hard to remove
    a package or to have an old and new version available
    simultaneously. (Compare the corresponding flaws in the rpm system.)

    If the package is called 'foo' it may have sub-directories such as
        foo/auto foo/lib foo/help foo/ref foo/teach foo/com foo/src
    etc.

    There should be a foo/AREADME file explaining what the package is
    and how to use it or where to look for information.

    A news file of some sort should record changes in reverse
    chronological order. This could be in the foo/ directory or
    in something like foo/help/foo_news

    If the package is to be made available by means of the pop11 command
        uses foo
    there should be a pop11 file
        foo/foo.p
    which extends search lists (e.g. popuseslist, popautolist,
    vedhelplist, vedteachlist, etc.), using the pop11 procedure
    extend_searchlist and the fact that the variable popfilename can be
    used to determine the location of the file being compiled.
    For an example see
        http://www.cs.bham.ac.uk/research/poplog/rclib/rclib.p

    When the package is installed a new symbolic link will be created
    from
        $local/lib/foo.p
    to
        ../foo/foo.p

    That will enable the 'uses foo' command to work, because by
    default 'uses' searches in $local/lib.

    The foo/foo.p file should normally NOT compile the whole package, as
    people may wish only to browse the code and documentation after the
    'uses foo' command, without the overhead (and possible confusion)
    caused by compiling code that is not to be run. So some additional
    'uses' command will normally be needed to compile the package (or
    sub-package) code, E.g. 'uses popvision' makes available a lot of
    documentation and many sub-packages, which require their own 'uses'
    commands, e.g. 'uses rc_array' 'uses canny' 'uses lapop' etc.