e68dca04e0
Normally we run ./configure from within the build tree, but autotools now allows doing out-of-tree builds by running configure while cd'ed to a different directory. Add a config variable `AUTOTOOLS_BUILD_PATH` to allow this on a per-package basis, and set this for the SDL2 package; SDL2 hg complains when doing in-tree builds because certain files get clobbered. |
||
---|---|---|
.. | ||
autoconf.sh | ||
automake.sh | ||
autotools.sh | ||
chocolate-doom.sh | ||
directx-devel.sh | ||
extra-libs.sh | ||
flac.sh | ||
fluidsynth.sh | ||
gettext.sh | ||
glib.sh | ||
libffi.sh | ||
libogg.sh | ||
libpng.sh | ||
libsamplerate.sh | ||
libtool.sh | ||
libvorbis.sh | ||
pkg-config.sh | ||
README.md | ||
SDL2.sh | ||
SDL2_image.sh | ||
SDL2_mixer.sh | ||
SDL2_net.sh | ||
zlib.sh |
Package files are shell scripts which set variables and call well-defined functions to describe how to build the package.
Modules
chocpkg
is divided into modules which provide specific functionality.
Modules are installed by calling certain dedicated functions.
Usually, your package should install a check module, a fetch module
and a build module.
Check modules
Check modules are modules which determine whether the package is
installed on the system (may have been installed by chocpkg
itself
or the system package manager).
If a check module is not installed, the default is to always
assume the package is not installed:
check_pkgconfig
: invokespkg-config
to determine if the package is installed. The name of thepkg-config
.pc file must be provided as an argument tocheck_pkgconfig
; for example:
check_pkgconfig SDL2
check_tool
: checks if a particular tool is installed in$PATH
to determine if the package is installed. The name of the tool must be provided as an argument tocheck_tool
; for example:
check_tool gnome-terminal
Fetch modules
Fetch modules specify how to retrieve the package from the Internet:
fetch_download
: downloads the package from a URL specified as an argument. The file to be downloaded is assumed to be a well-formed tar.gz file with all its contents in a directory that matches the package name; if this is not the case, the variable$IS_TAR_BOMB
should be set totrue
. Example use:
fetch_download http://example.com/example-pkg.tar.gz
IS_TAR_BOMB=true
fetch_git
: downloads the package from a Git repository at the URL given as an argument. The branchmaster
will be checked out by default; this can be overriden by providing the branch name as a second argument tofetch_git
. Example use:
fetch_git http://example.com/example.git my-neato-branch
Build modules
Build modules specify how to build the package after it is fetched:
build_autotools
: builds the package assuming that it is laid out as a standard autotools package (ie../configure; make; make install
). Extra arguments passed to the function will be passed through toconfigure
. Example use:
build_autotools --disable-broken-feature
Variants
Variants allow building of different versions of the same package. An
example is "latest stable release" vs. "latest version from source
repository". The default variant is called stable
. A variant can be
specified on the command line with a suffix, for example, to build the
variant latest
of package neato-lib
:
chocpkg install neato-lib/latest
In package files the variant
function is used for conditional code
that is only executed for a particular variant. Usually this is used
to select a fetch module. For example:
variant stable fetch_download http://example.com/neato-lib-0.0.1.tar.gz
variant latest fetch_git git://example.com/neato-lib.git
variant frob-branch fetch_git git://example.com/neato-lib.git frob-branch
By convention, the stable
variant is "the most recent stable release
of the package" while the latest
variant is "the latest version in
the source control repository".
Other modules and functions
dependencies
: Arguments provided to the function are the names of other packages to install before trying to build this one. Example use:
dependencies other-package neato-lib
package_group
: Specifies that this is not really a package that should be built; rather, it just specifies a number of other packages to build. Example use:
# File contains no other lines
package_group neato-lib dumbo-lib
Advanced builds
Complicated packages can require custom build steps. The following functions can therefore be overridden in the package file in exceptional circumstances. These are essentially the functions implemented by the modules described above.
-
do_fetch
: the function which is invoked to fetch the package from the Internet. The fetched package is placed into$PACKAGE_BUILD_DIR
for build. -
prebuild_setup
: define a function with this name to execute special setup commands in the root of a package just before it is built. -
do_build
: the function which is invoked to build the package. -
do_install
: the function which is invoked to install the package after it has been built. This function should install built files from$PACKAGE_BUILD_DIR
into$PACKAGE_INSTALL_DIR
.