Plasma GitLab Archive
Projects Blog Knowledge

GODI Project:
Home 
Highlights 
Screenshots 
Get GODI 
Docs 
Mailing List 
Resources 
Packages 
Workgroups 
OASIS 
Why Ocaml? 
GODI is discontinued. This is the archived content of the former site godi.camlcity.org.
======================================================================
Reference for PLIST
======================================================================

$Id: plist-ref.txt 562 2005-06-02 15:42:25Z gerd $

The PLIST file describes which files belong to the package. It is
interpreted at various stages of the build and installation process:

(1) After the just built package has been installed using "make
    install", and when it is required to record which of the installed
    files belong to the package

(2) When the binary tgz file is created from the installation by
    godi_create

(3) When a binary tgz file is installed by godi_add

(4) When a binary tgz file is removed by godi_delete

There are two versions of PLIST: A low-level version that is
understood by godi_create, godi_add, and godi_delete, and a high-level
version allowing a number of additional constructs that can be
transformed to low-level counterparts when required. Of course, the
high-level version is used for the PLIST file that is part of the
build instructions of the package.

This PLIST file can also refer to Makefile variables using the
syntax ${var}, provided that var is exported to the PLIST. See below
how to do this.

Historically, the high-level version was stored in a file called
PLIST.godi to distinguish it from a low-level PLIST. Typically, the
beginning of a Makefile was

GODI_PLIST=     yes
.include "../../mk/godi.pkg.mk"

Although this is no longer necessary (you can now use the high-level
constructs directly in PLIST), it is recommended to include these
lines in Makefiles for compatibility, and to keep the file name
PLIST.godi.

----------------------------------------------------------------------
File format & basic usage
----------------------------------------------------------------------

Every line contains one directive. Most directives have the form

@keyword argument(s)

There must be only one space between @keyword and the arguments!

If the line does not begin with '@' it simply lists the name of a file
to include into the package. The name must be given as a path relative
to the base directory of GODI (${LOCALBASE}). This way regular files
and symbolic links can be recorded.

Under Windows, ".exe" suffixes are automatically added to executable
files. In PLIST, these must be written without suffix.

Directories are now automatically managed: they are created when needed,
and they are removed when they become empty. In previous versions of
GODI, there used to be a @dirrm directive controlling when directories
are to be removed. This feature has been dropped.

If a directory needs special permissions, one can accomplish this with
an @exec directive (see below).

----------------------------------------------------------------------
Using variables
----------------------------------------------------------------------

As mentioned, it is allowed to reference variables in the PLIST or
PLIST.godi file that is part of the build instructions. These
references are resolved when the package is built, such that the
version of PLIST included in the binary package contains only the
expanded directives.

By default, one can use:

- Information about the operating system:

  ${OPSYS}
  ${OS_VERSION}
  ${MACHINE_ARCH}
  ${MACHINE_GNU_ARCH}
  ${MACHINE_GNU_PLATFORM}
  ${LOWER_VENDOR}
  ${LOWER_OPSYS}
  ${LOWER_OS_VERSION}

- Information about the package:

  ${PKGNAME}             = The package name including the version string
  ${PKGBASE}		 = The package name without version string
  ${PKGVERSION}          = The version string

- Information about this GODI instance:

  ${LOCALBASE}		 = The base directory of this GODI installation
  ${PKGLOCALEDIR}        = Where to install locales

- Shell commands:

  These variables expand to absolute paths to the corresponding
  commands (see @exec, @unexec):

  ${LN}			 = ln
  ${CHMOD}		 = chmod
  ${MKDIR}		 = mkdir
  ${RMDIR}		 = rmdir
  ${RM}			 = rm
  ${TRUE}		 = true

By adding to PLIST_SUBST, more variables of the make framework can be
made accessible for PLIST.

----------------------------------------------------------------------
High-level constructs
----------------------------------------------------------------------

@findlib <pkgname>
   include all files installed as findlib package <pkgname>. The
   findlib directories are recorded as private directories. Stub
   DLLs are NOT recorded.

   This directive does not work when the META file has a "directory"
   setting.

@dllfindlib <pkgname>
   As @findlib, but stubs DLLs (if any) are also recorded.

   This directive does not work when the META file has a "directory"
   setting.

@flatdir <dir>
   include the contents of directory <dir>, but not subdirectories.
   The directory as such is not recorded, one must add a @dirrm to
   specify this.

@deepdir <dir>
   include the contents of directory <dir>, with all subdirectories.
   The directories are recorded as private directories (no @dirrm
   necessary).

@glob <pattern>
   interpret <pattern> as shell glob. "*" does not match slashes.
   Only regular files can be matched (including symlinks if they
   point to existing regular files), but not directories.

@library <dir> <libname>
   include the files for library <libname> found in <dir>. <libname>
   must neither contain prefixes like "lib" nor suffixes like ".so".
   This is the same string that would be passed to the linker with the
   -l switch. The interpretation depends on the type of libraries:

   ELF and a.out: Includes all libNAME.so.VERSION, libNAME.a and libNAME.la
   MachO: Includes all libNAME.VERSION.dylib and libNAME.la
   PE: Includes all cygNAME.dll, libNAME.a and libNAME.la

   At least one file must be matched.

@stubdll <dir> <libname>
   include the files for the O'Caml stub library <libname> found
   in <dir>. <libname> must neither contain prefixes like "dll" nor
   suffixes like ".so".

   This directive is ignored when the platform does not support
   dynamic stublibs. Only _dynamic_ libraries are selected, for the
   static ones simply use @library. The findlib-typical .owner
   files are also selected by this directive.

Note that some of these high-level constructs may pick the wrong
files. For example, if the directory referred to by @flatdir contains
files owned by other packages, this will not be detected, and wrong
ownership information will be registered. Another problem may be that
@library records all versions of the mentioned library in the
mentioned directory. This may be wrong when two packages install two
versions of the same library.

There are also some conditionals. The <directive> is only executed
if the condition is true. 

@ocamlopt <directive>
   do <directive> only if ocamlopt is available

@ocamloptp <directive>
   do <directive> only if ocamlopt and gprof-support are both available

@ocamldll <directive>
   do <directive> only if ocaml DLLs are available

These conditions can be negated, e.g. @!ocamlopt negates the condition
of @ocamlopt.

Another important construct:

@optional <directive>
  performs <directive>, but "soft errors" are ignored. These errors
  are:
  - @findlib, @dllfindlib: The findlib package does not exist
  - @deepdir: The mentioned directory does not exist
  - @library, @stubdll: The mentioned directory does not exist, or 
    there is not any matching library in it

----------------------------------------------------------------------
Low-level constructs
----------------------------------------------------------------------

These are directly interpreted by the low-level package tools such as
godi_add. For a full list see godi_create(1).

@comment <string>
    A comment. As it seems certain forms of comments are used to
    put checksums into binary packages. It is unclear whether one can
    add comments freely.

@exec <command>
    Run this command when the package is installed by godi_add. One
    should only call commands by absolute paths. Examples:

    @exec ${LN} -s otherfile thisfile
    @exec ${MKDIR} directory && ${CHMOD} 500 directory

    Certain '%' notations are available, see godi_create(1) for a
    complete list. %D is the current working directory, which is
    the base directory if the @cwd directive is not used.

    The command is not executed when the package is built from
    source.

@unexec <command>
    Run this command when the package is removed by godi_delete.


This web site is published by Informatikbüro Gerd Stolpmann
Powered by Caml