packages builder
name=ohyeah
version=3.1.4.1.5
release=42
source=(niak)
build() {
cd $name-$version
make DESTDIR=$PKG build install
}
Our recipes are simple, and that’s what they are meant to be. We try to keep their syntax as intuitive, simple and clear as possible, to allow both easy maintaining and new ports creation.
In pkg++, there is no need to copy monstrous bunches of code from a recipe into another one, because we have another approach. Instead of copying content, we decided it’d be best to put it in a special place, where every single package could use it without massively generating duplicates. :)
No need to manually call curl, or wget, or for
those who download more, axel. We have a
$source variable, and everything in
it is downloaded using the available tools, and,
what more, those the builder wants to use.
Our $source can also contain the URLs
of versionned repositories, like git,
hg or svn repositories.
Many current packages building tools require you to
download the sources externally. In pkg++,
such downloads are automated using
$source.
pkg++ provides several tools to help you detect buggy or outdated recipes.
$lastver
pkg++ -cp
Experienced users may often feel limited by the tools they use, or forced to make ugly hacks to solve simple problems.
pkg++ tries to provide solutions to such problems without using hacks, with documentation, class, and hope wonderful recipes will be written using them.
pkg++, as any good software possesses a system-wide configuration file. But, also, it possesses several directories in which you can add configuration to be read before or after your recipe is parsed.
Seems pretty useless at first, eh? But what about providing additional configuration for a distribution in a separate file, defining package-based behavior, or even adding new kind of automatic tests at build-time.
Each user can define configuration for himself to build packages for his userdir, for any other alternate prefix, for any kind of non-root build or whatsoever.
Such configuration can also be called to cross-build or
build for a specific project, with the -cf
option.
Predefined configuration for particular cases, which you may want to use only at some moments, can also be written, and be rendered system-wide.
Such a flag is a keyword that embodies support and dependency-information for a certain concept.
pkg++ is one of the few packages builder to support use flags.
Some distributions split packages, or at least allow it.
But, what if a user wants to split a particular way,
instead of the way the packager did it? This is where
autosplits (automatic splits
) come in.
Automatic splits are the way users define how they want their packages to be split, allowing to separate manual pages, documentation, libraries, headers, or anything else from the main package. As they are used-defined or configuration-defined, they can also be used to be more compliant with the rules of your distribution.