Support GNU Autotools-style $prefix and $DESTDIR build settings

[Screwtapello]

Makefiles produced by GNU Autotools support two separate build settings that control where make install will install files:

• $prefix defaults to /usr/local, describes where files will be at runtime, and may be compiled into the executable
• $DESTDIR defaults to the empty string, describes where files will be placed at install time, and must not be compiled into the executable

The idea is that when building an RPM or DPkg package, distro maintainers can set $prefix to the path where the program will be installed on the target system, and set $DESTDIR to build it in some isolated temporary location that doesn't need root access to write to. For example, if the makefile says:

install out/myprog $(DESTDIR)$(prefix)/bin/myprog

...then a user may run make install to get /usr/local/bin/myprog, but a distro package may run make DESTDIR=/tmp/build/myprog prefix=/usr install to get /tmp/build/myprog/usr/bin/myprog, which gets archived into a package, which gets installed as /usr/bin/myprog.

bsnes does not support this scheme. There are no build settings to control what paths get compiled into the executable, so the only thing that matters is where files are placed at install time, which is effectively a combination of $prefix and $DESTDIR. In bsnes' build system, this setting is confusingly named $prefix.

However, while bsnes system is simple and self-consistent, it's inconsistent with the rest of the world and causes confusion and grief for people trying to integrate bsnes with any kind of larger packaging system. Although it makes bsnes a little more complicated, we should add $DESTDIR support to the build system, probably along the lines of:

• add a new, empty DESTDIR variable to nall/GNUmakefile, near where prefix is declared
• add $(DESTDIR) to all the Linux/BSD install commands in bsnes/target-bsnes/GNUmakefile

[Screwtapello]

Note that supporting all the GNU Autotools install path variables probably isn't going to happen, because that's a lot of work and if we really wanted to be compatible with GNU Autotools, we'd just use it as our build system directly.