Plasma GitLab Archive
Projects Blog Knowledge

GODI Project:
Mailing List 
Why Ocaml? 
GODI is discontinued. This is the archived content of the former site
Reference for makefile variables

$Id: makevar-ref.txt 1187 2014-05-25 16:43:23Z gerd $

The notation

var (flags)

means that for the variable "var" the annotations indicated by the
"flags" must be taken into consideration. List of flags:

- r: For a package "Makefile" this variable is read-only, i.e. it can
     be used, but it must not be modified

- w: For a package "Makefile" this variable is read-write

- c: configuration: This variable can be set in godi.conf

- f: preference: This variable is set by, so you need only
     to include this makefile, not the whole of

- p: This variable is private for the make framework

- !: The meaning of the variable has changed, pay attention to which
     version of godi-core-mk interprets it in which way

Global configuration

    When "yes", package tests are enabled.

    (I don't know of any such test, however.)

    If set to "yes", the packaging step "godi_make install" is modified,
    and it is checked whether the PLIST of the packages cover all
    freshly installed files. This is recommended for package developers.

    This can be set to a list of URLs or directories from where binary
    packages are received.

    A list of URLs where to find build.tgz files (build instructions).
    Note: Since Skylift, this list is set in the profile. Avoid to set
    it in godi.conf unless for experimentation.

    The primary URL with build.tgz files. The primary URL is used during
    bootstrap. It is usually the first URL of GODI_BUILD_SITES.

    Note: If both GODI_BUILD_SITE and GODI_BUILD_SITES are set, the latter
    has precedence.

    Not used in Skylift anymore.

    The selected release line, e.g. 3.07. Changing this variable normally
    changes GODI_BUILD_SITES and GODI_BUILD_SITE implicitly, too.

    Backup URLs of the GODI project for distfiles.
    Note: Since Skylift, this list is set in the profile. Avoid to set
    it in godi.conf unless for experimentation.

    Profile-specific distfile URLs

    If set, the distfiles are first tried to be fetched from this URL
    (or URLs).  This can be used to direct GODI to use a local cache
    of the distfiles as first download choice. The other sites
    (package site, backup sites) are tried later when the file is not
    configure that the backup sites are tried first.
    (NB: In Skylift this is the default.)

    List of directories where to search for C libraries by default.
    This should be base directories in the sense that when /dir
    is in this list the libfoo.a file is found in /dir/lib, the
    include files are found in /dir/include etc.

    This variable is initialized with a reasonable default.
    If you set this variable in godi.conf, your settings are
    prepended to this default.

    Same contents as SEARCH_LIBS, but overrides the search
    path completely (no default), that means SEARCH_LIBS does
    not have any effect.

    List of directories where GODI searches Unix utilities. This list
    is only used when godi-core-mk is configured ("Looking up system
    commands"). godi-core-mk uses the current value of this variable
    to determine the absolute paths of the Unix commands before this
    package is installed, and writes this value into after
    this package is installed, just to have it for the next build. The
    initial value is written by the GODI bootstrap script.

    By setting this variable or appending to it in godi.conf, one can
    change the command path for the next time godi-core-mk will be
    installed. It does not have any further effect.

    The paths found out with the help of SEARCH_CMDS are usually only
    used by the GODI make framework, but not by the invoked upstream
    build scripts.


    Set this variable to the absolute name of a directory to
    configure that builds are performed in this directory. E.g.

    If set to "yes", the Gentoo sandbox is used to restrict
    the package build and install to "legal" directories.
    This is just a QA measure, e.g. used for GODI autobuilders,
    and should not be taken for a security feature. Get the
    Gentoo sandbox from;a=summary

    The sandbox is invoked as $SANDBOX_CMD, defaulting to just

-- OS-specific --

OPSYS (cf)
    The base name of the operating system:
    Linux, SunOS, NetBSD, FreeBSD, OpenBSD, Darwin etc.

    Note: All Windows ports use the name of the scripting environment.
    This is always "CYGWIN" for now.

    Same as OPSYS in lowercase letters

W32PORT (cf)
    Only set for native Win32 ports:
     - "mingw": The MinGW toolchain is used
     - "vc": The Visual C++ toolchain is used (not yet implemented)

    This variable is empty or unset for Unix, including Cygwin.

    The version as reported by uname

    Same as OS_VERSION in lowercase letters

    The vendor as reported by uname




    see finding-libraries.txt

    Note when CREATE_SHLIBS is set and "no", C libraries must only
    be installed as static archives, and it must not be tried to
    create shared libraries.

    If unset, or not "no", C libraries should be installed as
    shared libraries.

    For O'Caml stub libraries, see GODI_HAVE_DLL, it has a similar

    see finding-libraries.txt

    see finding-libraries.txt

    see finding-libraries.txt

    compatibility name for ELF_RPATH_FLAG


--- Global directories ---

    The base directory where GODI is installed.

    The base directory where GODI is installed. For native Win32 ports,
    this variable contains the Windows path (with drive letter, using
    forward slashes). For other ports it is identical to LOCALBASE.

    The base directory used for install time. Currently, this is
    always the same as LOCALBASE, but alternate installation
    methods might need it

    The directory containing the package database

    The "distfiles" directory (tarballs with sources)

    The "packages" directory (binary packages)

    The directory containing profile patches

--- Per-package directories ---

These variables are per package.

    The package directory containing the build instructions

    The "work" subdirectory in PKGDIR

    The directory with the unpacked package sources (usually below

    The directory containing patches, i.e. "patches" in PKGDIR

    The directory containing additional files, i.e. "files" in PKGDIR

O'Caml-specific global configuration



Note that the following options about the capabilities of the O'Caml
installation are meant as documention about available or missing
features. By setting them you cannot turn off these features! Build
scripts can test them, however, and build packages according to their

    "yes" or "no": whether there is an ocamlopt compiler

    "bthr" or "pthr": "bthr" means that there is only the bytecode
    thread model, "pthr" means that both thread models are supported,
    bytecode threads and POSIX threads.

    "yes" or "no": whether O'Caml supports stub libraries that
    can be dynamically loaded into the running _bytecode_ interpreter.

    When CREATE_SHLIBS=no, it is ensured this variable is also "no".

    "yes" or "no" or undefined (="no"). Only set since O'Caml 3.11.
    Whether O'Caml supports native-code plugins than can be dynamically
    loaded into the running native-code program.

    When CREATE_SHLIBS=no, it is ensured this variable is also "no".

    "yes" or "no": whether the ocamlopt compiler supports gprof-
    style profiling

    undefined or "yes" or "no" or "revised": 
    - undefined: old versions of godi-ocaml-src did not define this
      variable. Interpret this value as "don't know".
    - no: The -pack option is not supported.
    - yes: The -pack option is supported in the way O'Caml 3.08
      handles packing.
    - revised: The -pack option is supported in the way O'Caml 3.09
      handles packing. Note that all version of 3.09 support packing,
      so "no" is no longer possible.


These are (usually absolute) paths to utility programs, sometimes with
default arguments.

In Makefiles, the utilities must be called with these variables in
order to control which version is actually used (a number of OS have
several versions of the same utility).

We do not specify here exactly which version of the utilities can be
expected. As a rule of thumb, the Single Unix Specification can be
assumed. Note that GNU often has much more functionality which should
not be used, and that BSD often has a traditional interface which
should not be used, too. 

See also SEARCH_CMDS for how to change the search path for the
script that looks these commands up. Of course, it is also possible
to set these variables individually in godi.conf.

AR (cf)
    The ar utility

AWK (cf)
    The awk utility. One can assume nawk functionality.

    The basename utility

BZCAT (cf)
    The bzcat utility. This is optional.

BZIP2 (cf)
    The bzip2 utility. This is optional.

CAT (cf)
    The cat utility

CHMOD (cf)
    The chmod utility

CMP (cf)
    The cmp utility
CP (cf)
    The cp utility

CPP_EXE (cf)
    Path to a stand-alone C preprocessor (for applications requiring
    one, such as rpcgen)

CUT (cf)
    The cut utility

DATE (cf)
    The date utility

    The digest utility. This is always the version installed at
    GODI bootstrap time (godi_digest)

    The dirname utility

ECHO (cf)
    The echo utility

EGREP (cf)
    The egrep utility.
    CHECK: Is this actually used? Better transition to ${GREP} -E

EXPR (cf)
    The expr utility

FALSE (cf)
    The false utility

    The utility to download files. Related:

        Arguments for FETCH_CMD to place before the download URL, and
	after the download URL, resp.

    The download utility must have certain properties not described here.

FGREP (cf)
    The fgrep utility
    CHECK: Is this actually used? Better transition to ${GREP} -F

    The file utility

FIND (cf)
    The find utility

GCC (cf)
    How to invoke the GNU C-compiler. Defaults to "gcc" without path.
    E.g. add "-V" options to select certain version of the compiler.

    "gcc" must never be referenced by absolute path.

GMAKE (cf)
    The GNU make utility

GREP (cf)
    The grep utility

GTAR (cf)
    The tar utility. (CHECK)

    The gunzip utility

    The gzip utility

GZCAT (cf)
    The gzcat utility

HEAD (cf)
    The head utility

    The hostname utility

ID (cf)
    The id utility

    The BSD-compatible install utility. If the OS does not have one,
    the godi_install script is used instead

    The ldconfig utility, or "true" if the OS does not have one

LDD (cf)
    The ldd utility, or "true" if the OS does not have one

LN (cf)
    The ln utility

LS (cf)
    The ls utility

M4 (cf)
    The m4 utility

MKDIR (cf)
    The mkdir utility plus -p option

MV (cf)
    The mv utility

NM_EXE (cf)
    The nm utility

PATCH (cf)
    The patch utility

PAX (cf)
    The pax utility. This is always the version installed at GODI
    bootstrap time.

    The printf utility

PWD_CMD (cf)
    The pwd utility. It is ensured that the version of pwd is put in
    here that prints the physical path

    The ranlib utility, or "true" if the OS does not need this

RM (cf)
    The rm utility

RMDIR (cf)
    The rmdir utility

SED (cf)
    The sed utility

    The env utility

SH (cf)
    The preferred shell

SORT (cf)
    The sort utility

    The strip utility, or "true" if the OS does not have one

TAIL (cf)
    the tail utility

TEE (cf)
    The tee utility

TEST (cf)
    The test utility

TOUCH (cf)
    The touch utility

TR (cf)
    The tr utility

TRUE (cf)
    The true utility

TYPE (cf)
    The type utility

WC (cf)
    The wc utility

WGET (cf)
    The wget utility (try not to use this var - the download will be
    redesigned soon)

    Options for wget. This is set to some reasonable default, but can
    be overridden (i.e. you can set other timeouts)

XARGS (cf)
    The xargs utility

	This variable enumerates the variables that should go into
	ESSENTIAL_ENV. These are mostly variables with utility

	The environment containing the utility programs enumerated

General package description

These variables are per package.

    The name of the package and the version string, separated by "-".
    For example: godi-core-mk-3.5

    When setting this variable in "Makefile", the version string must
    not have a revision suffix like "godi4". However,
    appends this suffix, and sets PKGNAME_NOREV to the original,
    suffix-free name.

    If this variable is not set in a package "Makefile", DISTNAME will
    be used instead, and must be set to the package name plus version

    The name of the package plus version string, but without revision

    The package revision, a decimal number. This number is appended
    to PKGNAME, separated by "godi", when the name of the .build.tgz
    file is constructed, e.g.

    When the PKGREVISION is 0, no "godi" suffix is appended to the
    file, however. This is the same as not defining PKGREVISION at

    The package revision should be increased when the build
    instructions are updated for the same version of the upstream

    The name of the package without version string, derived from

    The version string of the package only, derived from PKGNAME.
    Of course, this implies that there is no revision suffix, too.

    The "distibution name" as chosen by the upstream author. This
    should be set to the name of the directory that is created when
    the source tarball is extracted.

    The name(s) of the source tarball(s). By default, this is DISTNAME
    plus EXTRACT_SUFX (.tar.gz)

    An optional prefix to prepend to the DISTFILES when downloading the
    files, e.g. the file "foo-1.2.3.tar.gz" would be locally stored
    as "prefix-foo.1.2.3.tar.gz" if "DISTPREFIX=prefix-". This can
    be useful for working around conflicting names. 
    (Since godi-tools-3.0.19.)

    The names of distfiles and patches without checksum, i.e. the
    checksum verification step is skipped for these.

    The tarball suffix, by default .tar.gz. The framework supports
    these suffixes: .tar.gz, .tgz, .tar.bz2, .tbz, .tar.Z, .tar,
    .shar.gz, .shar.bz2, .shar.Z, .shar, .Z, .bz2, .gz

    (Support for zip, lha, zoo has been removed!)

    The name(s) of the source tarball(s) to extract. By default, the
    same as DISTFILES.

    A list of categories. Currently, GODI defines only "apps", "base",
    "conf", and "godi".

    A description who maintains this package. Should contain name and
    email address

    The file containing the long package description. 
    Defaults to DESCR in the package directory.

    The file containing the pack list.
    Defaults to PLIST in the package directory. If GODI_PLIST is
    defined, it defaults to PLIST.godi instead.

    Format of the file: see plist-ref.txt

    Changes the default for PLIST_SRC.

    In early versions of godi-core-mk, this variable also triggered
    the interpretation of additional PLIST directives.

    Contains a substitution for variables in PLIST. One can add
    further variables in the format NAME=VALUE, where VALUE should be

    The file containing the message displayed when a binary package
    is added. Defaults to MESSAGE in the package directory if this
    file exists

    Contains a substitution for variables in MESSAGE. One can add
    further variables in the format NAME=VALUE, where VALUE should be

    Enumerates the strict dependencies on other packages, i.e. it
    enumerates other packages that must be present when this package
    is used.

    The format is a space-separated list of dependencies like:


    Here, <PKGBASE> is the base name of the other package, without
    version string. <OPERATOR> is one of ==, !=, >=, >, <=, <.
    The <VERSION> is a version string without revision suffix.
    <CAT> and <PKGDIR> are chosen such that the part after ":"
    is the relative path to the package directory (note that this
    part is only interpreted by some legacy scripts, godi_console
    ignores it; however, it should be present for now).

    The exact algorithm comparing version strings is described
    elsewhere. The parts of hierarchical version strings must be
    separated by ".". The parts can be decimal numbers or alphanumeric
    strings. The keywords "pre", "test", "alpha", "beta", "rc", "pl" are 
    handled specially.

    Note that package revisions are ignored for the comparison.

    If the version does not matter, use


    or, maybe better,


    (with ">=").

    In ancient versions of GODI it was required to add a path to a
    dependency, e.g. "godi-foo>=3.14:../../godi/godi-foo". Such 
    paths are now ignored.

    Enumerates the build dependencies on other packages, i.e. it
    enumerates other packages that must be present when this package
    is built.

    The format is the same as for DEPENDS.

    Enumerates conflicts with other packages or package versions.
    The syntax is simply


    i.e. _without_ the colon and the directory!

    This variable should only be set if godi_console supports it.
    Use a test like


    URLs of directories where to download the DISTFILES. The URLs must
    end with a slash.

    (since godi-tools-3.0.38)
    full URLs where to download the files (i.e. the URL refers to the
    file directly and not to the directory containing it like MASTER_SITES).
    This can be used instead of MASTER_SITES, especially if the URLs don't
    contain the right filename.

    URLs where to download the PATCHFILES. The URLs must
    end with a slash.

    Used internally by GODI to signal that an alternate
    installation method must be used.

Variables controlling the build

These variables are per package.

	If defined, the configure script must be called

	If defined, the configure script must be called, and it can be
	assumed that it is a GNU autoconf-style script

	The environment to use for "configure". The format
	of this variable is a space-separated list of NAME=VALUE
	strings that can be parsed by the shell. By
	default, a lot of variables are already defined. To add
	variables, use this syntax:


	(The :Q modifier enables shell quoting.)

	If "yes", a number of additional variables are added to
	CONFIGURE_ENV, in particular these of ESSENTIAL_ENV.

	The name of the configure script to call. Defaults to

	Arguments passed to the configure script.

	Enumerates the directories where "configure" is to be invoked.
	By default, only the WRKSRC directory is taken.

	When defined, GNU make is used to build/install the package; otherwise
	BSD make is used

	When defined, omake is used to build/install the package; otherwise
	BSD make is used

	The selected version of the "make" utility

	The environment to use when "make" is called to build/install the
	package. The format of this variable is a space-separated list of
	NAME=VALUE strings that can be parsed by the shell. By
	default, a lot of variables are already defined. To add
	variables, use this syntax:


	(The :Q modifier enables shell quoting.)

	If "yes", a number of additional variables are added to
	MAKE_ENV, in particular these of ESSENTIAL_ENV.

	Arguments passed to "make" when it is called to build/install the

	Att: There is also MAKEFLAGS, but this has a different meaning.

	The name of the makefile when "make" is called to build/install the
	package. Defaults to "Makefile".

	The "make" target to build the package. Defaults to "all"

        The complete command to run for building. By default, 
        MAKE_PROGRAM is invoked with an ALL_TARGET.
        (Since godi-tools-3.0.19.)

	Enumerates the directories where ALL_TARGET is invoked.
	By default WRKSRC.

        (By setting this to the empty string you can disable the build.)

        The complete command to run for testing. By default, 
        MAKE_PROGRAM is invoked with a TEST_TARGET.
        (Since godi-tools-3.0.19.)

	The "make" target to test the package. This is not defined
	by default, and no test is done. To enable tests, one must
	also set PKGSRC_RUN_TEST.

	Enumerates the directories where TEST_TARGET is invoked.
	By default WRKSRC.

	The "make" target to install the package. Defaults to

        The complete command to run for installing. By default, 
        MAKE_PROGRAM is invoked with an INSTALL_TARGET.
        (Since godi-tools-3.0.19.)

	Enumerates the directories where INSTALL_TARGET is invoked.
	By default WRKSRC.

        (By setting this to the empty string you can disable the install.)

	When defined, resource restrictions are removed (ulimit)
	before a package is built

        If set, it is checked at installation time whether these
        findlib libraries already exist, and if so, the installation
        is rejected.

        Set this to a space-separated list of findlib libraries.

        (Since godi-tools-3.0.19.)

OASIS builds

For supporting OASIS conventions:

        if set to "yes", a number of variables are set to different

        CONFIGURE_SCRIPT=ocaml -configure
        BUILD_SCRIPT=ocaml -build && ocaml -doc
        INSTALL_SCRIPT=ocaml -install

        Also, CONFIGURE_ARGS are filled with arguments like --prefix.
        The option --destdir is also passed, and AUTOGENERATE_PLIST 
        is set (i.e. the oasis package MUST interpret --destdir).

        (Since godi-tools-3.0.19.)

	If set to "yes", CONFIGURE_SCRIPT is initialized differently.
	In particular, is regenerated by calling the
	"oasis" program. According to Sylvain this is recommended,
	and hence this option defaults to "yes".

	(Since godi-tools-3.0.27.)

Autogenerated PLISTs

Some packages have the option to install into a prefix. This is
can be exploited:

        If set, it is expected that the package install into a
        subdirectory of ${WRKDIR}/image. The files found there
        are collected, and a PLIST is autogenerated.

        Set this to the subdirectory of ${WRKDIR}/image that
        corresponds to ${LOCALBASE} in the final install.

        Defaults to ${WRKDIR}/image.

        (Since godi-tools-3.0.19. Before, PLIST autogeneration always
        acted as if AUTOGENERATE_IMAGE=${WRKDIR}/image.)

Variables controlling details of the build

--- traditional toolchain control ---

CC (c)
        The name/path of the C compiler. This should be the same C
        compiler that is invoked by the ocaml toolchain, and hence
        it MUST be already set at bootstrap time.

        Do so by: CC=<value> ./bootstrap <args>

        The value of CC is saved in godi.conf. There is no default if
        it is left unset.

CPP (cw)
        The name/path of the C++ compiler

        Additional flags to pass to the C compiler. This variable
        is only honoured by "traditional" builds. If the C compiler
        is invoked via "ocamlc", CFLAGS is ignored by default, unless
        the option -ccopt "$(CFLAGS)" is added.

        Additional flags to pass to the C++ compiler

        Additional flags for the linking step. GODI sets this by
        default to "-L $(LOCALBASE)/lib".

Site patches

These patches are provided by the site using GODI, and are applied to
packages when they are built.

	The variable must contain the base directory for site
	patches. The site patches for package cat-foo are then found
         in the directory $LOCALPATCHES/cat/cat-foo (here, cat is the
         package category like "apps", or "godi", and foo is a
         placeholder for the name). For example, the patches for
         godi-ocamlnet would be expected in $LOCALPATCHES/godi/godi-ocamlnet.
	The patches in this directory are handled as if they were in
	the "patches" directory of the build directory. The patch files
	should obey the name convention "patch-LL-SUFFIX" where
	LL are two letters specifying the order in which all packages
	are applied (i.e. in alphebetical order). SUFFIX is an
	arbitrary suffix, usually describing the patched file.
	Patches should be in unified form (produced with
	diff -Naur); file names must be relative to the
	source directory ($WRKSRC), i.e. create patches with

	diff -Naur file ... >$LOCALPATCHES/cat/cat-foo/patch-LL-SUFFIX

	Pitfall: Don't leave files ending in ~ in this directory,
	they are also treated as patch.

        Since Skylift, it is now easy to create patches. See the
        User's Manual for instructions.


        The directory where exports are placed.

        The directory where buildfile exports are placed.
        (Default: $(EXPORT_DESTDIR)/buildfiles)
        The directory where distfile exports are placed.
        (Default: $(EXPORT_DESTDIR)/distfiles)

        The directory where profile exports are placed.
        (Default: $(EXPORT_DESTDIR)/profiles)

        The directory where binary package exports are placed.
        (Default: $(EXPORT_DESTDIR)/packages)

        The directory where seed exports are placed.
        (Default: $(EXPORT_DESTDIR)/seeds)
        The GODI_SECTION assumed for the exported objects
        (Default: $(GODI_SECTION)

        The source name of the export

        The profile name of the export
        (Default: current profile name)


	The value 0 means that no debugging output is generated.
	The value 1 means that shell commands are echoed before they
	are called.
	The value 2 means that the shell is even called with "-x"
	flag to echo even more commands.

	This variable should be set on the command line, e.g.
	godi_make build PKG_DEBUG_LEVEL=2

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