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.
This conveniently allows a whole set of packages to be installed from
a single command, without needing an actual package to be built that
depends on them all.
Not sure what the practical upshot of this is yet, but it at least
allows it to build successfully. I've been unable to get it to build
with DirectX support enabled yet because the compiler complains about
missing header definitions for LPDIRECTINPUTDEVICE8 and related
functions.
This is a tricky package to support, since the tar file is improperly
structured and it is not an autotools package. Refactor slightly and
add IS_TAR_BOMB option for this kind of use case.
Now that buildenv.sh is mostly just for setting BUILD_HOST, include
it early in the chocpkg initialization/startup. Set PKG_CONFIG_LIBDIR
as part of configure_for_package - this needs to be set before we
invoke pkg-config to check if the package is installed on the system
already, otherwise we can pick up a system package rather than the
one for the target architecture.
The 'install' command does nothing if the package is detected to be
already installed, but there are circumstances where we will want to
trigger a rebuild and reinstall explicitly. Separate out into two
commands, one of which is a superset of the other.
We need to distinguish between tools we compile to use as part of the
build process, and things we build for the eventual target. Install
these into separate install directories; for now, pkg-config is the
only one of these.
