Missing make dependencies for .xpm files

[0cjs]

Some (but not all) of the res/*.xpm files are generated but have a broken dependency graph. For example, make clean build/asset.o will fail because it has #include "../res/splash.xpm" but no dependency arc to ensure that gets built first. This kind of thing causes mysterious random failures in parallel builds (make -j8).

As well as fixing this, it would also be nice to keep the source .xpm files and the object .xpm files in separate directories, to make it easier to distinguish the two when debugging problems like this. perhaps move the generated .xpm files to build/?

[ThorstenBr]

The dependencies are actually there: they are automatically created. For each source file the proper list of dependencies is automatically created (and updated). So when a resource changes, this triggers an update of the generated header files, before compiling any source including the generated header.

The issue is that the dependencies are only created as a side-effect of the rule to compile a source. So the automatically generated dependencies are not available for the very first build (or after a 'make clean').

Manually maintaining the dependencies for individual files is ugly. There's at least three ways to fix this:

a) Botch in an exceptional make rule for the initial build, when dependencies are still missing (e.g. the "build" directory does not yet exist / no dependency ".d" files exist yet), so all resources are processed first in this case.

b) Separate the dependency generation from the build, so dependencies are fully generated first - and then already considered for the initial compile step of the sources.

c) Use a "makefile generator" like autotools or cmake, rather than manually coding the makefile. These build tools will already take care of such issues and generate proper makefiles.

Obviously (a) is the easiest fix. (b) would be cleaner but takes more effort. (c) is a larger and more fundamental change, which might trigger a basic discussion about the preferred build toolkit to use (usually an "autotools" vs "cmake" discussion these days). Moving on to a build tool would also help with other issues though, like #73.

[rhaleblian]

I'm not getting any build order issues. Note that I'm using a revised Makefile from #119.

1. moreover, now that the image targets are ephemeral, there's less chance of timestamp-related fails for Make.
2. building images is still based on "glob-like" rules, being less verbose to maintain;
3. those rules are called out by the rules requiring them;
4. since (2) and (3), seems like we don't have to go so far as to invoke autotools, Make-makers, etc.