I didn't check that it also *installs* all of it's components! That's
what I get for not having a list of package contents... although I'd
probably just end up missing something there instead.
I did the thing againnnnn. The Makefile thinks the sound assets are
constantly out-of-date because the folder that contains them technically
changes any time a file is added or removed from the folder.
1. "out/assets" is created, it is up-to-date
2. "out/assets/example.ogg" is created, it is up-to-date
3. Parent folder "out/assets" has it's mtime updated because it's
contents have changed. It is newer than it was at step 1, and newer
than the .ogg file in step 2.
4. run `make` again
5. "out/assets" is up-to-date, nothing changes
6. "out/assets/example.ogg" is OLDER than one of it's dependencies
("out/assets/"), and is rebuilt.
7. "out/assets" got new contents, so it's mtime was updated again.
The cycle isn't infinite, but it will always try to rebuild the sound
files. The fix is to consider the containing folder to only be an
ordering dependency rather than a substantive dependency. The former
only needs the dependency to be made first, where the latter considers
the dependency to be part of the target file. The containing folder is
not part of the sound files, so "rebuilding" the sound files when the
folder changes is complete nonsense.
Makefiles are pretty strange things.
There is a new wildcard target which will copy any .ogg file from
"assets/" into "out/assets". On it's own, it does nothing -- it only
knows how to create the output file by copying the input one.
To drive this, a list of output assets must be created and depended upon
by the main build target(s). I don't want to manually maintain an asset
manifest in a Makefile, so I've achived this by wildcard matching
anything in the "assets/" folder, then rewriting the prefix to be
"out/assets/". This list is in a variable, which is now part of the
dependency list for the main build target(s). All files will be
installed, but only when they are out-of-date. Excellent.
Variables that a package consumer might want to adjust should be placed
at the top of the file so they are immediately visible. Any constants
shall live below those (just the SRC folder, really).
