chocolate-doom sdl2-branch no longer depends on SDL2_image as of commit
chocolate-doom/chocolate-doom@7215d13b6c, so remove this dependency
and the SDL2_image package.
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.
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.
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.
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.
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.
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.
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.
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.
