[info] This is GODIVA version 0.9.5. Usage: godiva [options] spec -localbase <dir> specifies a GODI localbase instead of $GODI_LOCALBASE -patch <patch> includes the given patch -filesdir <dir> includes the given hierarchy of files -camlsyntax use the ocaml syntax (devel only) -refetch refetches the distfile instead of using a cached one -nosquash fail if an old package is in the way -quiet do not print informational messages -veryquiet do not print warnings or informational messages -version display version information and exit -help display this help information and exit --help display this help information and exit
Some fields are optional. Fields must be given in the order specified here.
Comments should be between (* and *), and they may be nested.
The name of the package, prefixed by its category and a '-'. For example, the piece of software named "foolib" with category "godi" gets the name "godi-foolib". Current GODI-supported categories are as follows:
This must begin with a digit, and may not contain the "-" character.
This refers to the release of the GODI package, not the version of the software itself. The first time a given piece of software is packaged, it should have revision 0. A newer revision is needed if something significant is added to the GODI package that should urge users to update, e.g. a security patch is applied. This should always be a single integer.
Depends: [<dep> <dep> ...]
Build-Depends: [<dep> <dep> ...]
<dep> has the following syntax:
<category>-<name> [(<relop> <version>)]
Legal relops include: >, <=, <, >, and ==.
godi-ocaml (> 3.06) conf-foo
The url at which the source tarball can be found. For example:
If the source tarball does not unpack to a directory whose name is not the same as the basename of the tarball, you can specify the name of the directory it unpacks to here.
The target that is used to make bytecode defaults to
the target that is used to make optimized code defaults to
Here you can specify what targets to use.
The url of the homepage for the project. For example:
Maintainer: <name> <email>
The GODI package maintainer's name and email. The email should be surrounded by angle brackets. For example:
Owen Gunden <firstname.lastname@example.org>
Options: [<opt> <opt> ...]
Legal values for <opt> include:
|configure||If the software requires that a configure script be run before it will compile.|
|bmake||If the software requires BSD-make instead of GNU-make.|
|opt||If the software has a separate target to make native code.|
|htdoc||If the software provides html documentation (not yet implemented)|
Docfiles: [<file> <file> ...]
These are the names of files which will be copied into the package's
should be specified relative to the top-level directory of the expanded
README, VERSION, doc/README.too, LICENSE
As of version 0.9.6, you can also specify directory names to have the entire directory copied into the package's doc directory.
The short description should fit all on one line. The long description must be terminated with a `.' character on a line all by itself.
Patches should have names like
XX is a two-letter code, and
NAME hints at which file
is to be patched. Since the patches will be sorted by name before being
XX code is used to indicate an order in which to
apply multiply patches.
For patches that are not in the top-level directory of the target sources,
the filename should have a name like
convert the slashes to dashes. And the patch header must contain the path
to the file, e.g.
---subdir/Makefile.orig [...] +++subdir/Makefile [...]
Patches can be included with the
-patch argument to godiva.
If you need any extra files to be copied into the top-level directory of the
expanded tarball just after it is expanded, you must use the
-filesdir option to godiva. You may indicate that the file is to
be placed in a particular subdirectory of the top-level tarball expansion by
placing it in a particular subdirectory of the files directory. For example:
bar.mldirectory into the
foosubdirectory of the top-level tarball expansion.