Since we're downloading arbitrary executable code from websites and
running it, we should at least have some confidence it's the right
thing we're running.
Download these from the maintainers' websites where possible, and
document in a couple of cases why we're still using the mirror. In the
future we can possibly make an automated/generic mechanism for providing
a mirror for files used by chocpkg.
If we check out from a VCS repo and configure is missing, we need to
run autoreconf to generate it. But check if autoreconf is actually
installed and exit with a useful error if it isn't.
Bash 3 accepts ${array[@]:0} but this is invalid in bash 4 for empty
arrays. Instead, use ${!array[@]} to get indexes into the array and
look up entries using them.
The chocolate-doom package currently only has a latest variant, so
this assumption is incorrect. Instead only make this assumption if
the package file declares no variants. Add variant list to the 'info'
command output.
By default we build the stable variant but provide a user-editable
list of packages which will be built at the latest variant instead.
Rename chocolate-doom-git package to chocolate-doom and have it use
the latest variant for the current Git build.
Any variant name can be specified on the command line, but only
certain variants will be supported by a given package. Detect which
are valid for a given package and exit with an error if a request is
made for an invalid variant.
It's nice to be able to build from source control HEAD, and
especially for packages under than Chocolate Doom itself. As a start,
define "latest" variants for all the SDL2 packages.
Slim down the library as much as possible, and link directly against
libpng rather than searching for it at runtime (so that the OS X
package building code will find libpng correctly).
This is important for pkgdef files like SDL2_mixer which recursively
invoke chocpkg to check if a soft dependent package is installed. In
this case it's important to explicitly prefix the package type to
pass it through to the recursed instance.
Since package groups can theoretically now be installed as
native:package-group as well, make PACKAGE_TYPE only ever have a value
of "target" or "native". For a native install it's important we
transform the names of all dependencies to have the native: prefix.
It doesn't matter if we uselessly set PACKAGE_INSTALL_DIR and
PACKAGE_BUILD_DIR for a package group anyway, since they're not used
anyway.
Previously a particular package could only ever be installed to target
or native. Instead, allow any package to be installed to either, with
target being the default. Native packages can only ever have native
dependencies, but target packages can depend on native ones in order to
install tools which they need for their build process.
Because we have to set up a particular environment before running
autoreconf, it's desirable to be able to do this by running chocpkg
build. However, to support this use case we need to be detect when the
configure script is out of date. Make the logic for when to run
autoreconf take this into account, rather than just checking for when
the file doesn't exist.
Technically these are not native or target type packages, as we are
not building anything; they may be made up of many packages of
different types. So make sure that 'chocpkg info' shows something
distinct and different for this kind of package.
The new commands are: info, packages and dependencies. The main one
is 'chocpkg info' which allows a description of a package (or of all
packages) to be shown, along with its status.
The only place this is needed is when determining the directory name
that the tar file will be extracted to. This can be done by examining
the .tar file name without needing to know the version itself.
Both of these set environment variables that allow libraries etc. to
be located. It's quite plausible that some implementations of the
check_installed function might depend on values of CFLAGS, LDFLAGS and
so on to check if a library is installed. Therefore, just set all these
variables in a single common function only invoked just before build, or
before performing an 'installed' check.
The pkg-config variables can affect how a package is discovered, and if
set by a package that depends on another, could lead to the recursive
call to chocpkg producing the wrong result. Instead, set only when
specificly needed (by build or check_installed), and always invoke
commands by recursively invoking the script, never by function call.
This has turned out to not do very much, and adds an annoying initial
stage before building. Just move this logic into the main script
instead, and get rid of it.
These modules encapsulate individual pieces of functionality and make
the code far more maintainable. This is a pretty big refactoring but
overall a big win.
Simon Howard
Simon Howard