Some of the files in "libsrc/*/extra/" include other library files. But, the "lib/*.o" files weren't rebuilt when those other files changed.
The new dependency rules must be "bootstrapped". You must force a rebuild of all of the extra library object files (it will create the dependency files). Use these commands:
rm lib/*.o
make lib
Kym Greenshields <kym.greenshields@gmail.com> has expressed interest
in contributing and maintaining support for the VTech CreatiVision system.
this resembles commit 8e6b8dd0af from oliver
Up to now static drivers were created via co65 from dynamic drivers. However there was an issue with that approach:
The dynamic drivers are "o65 simple files" which obligates that they start with the 'code' segment. However dynamic drivers need to start with the module header - which is written to. For dynamic drivers this isn't more than a conceptual issue because they are always contain a 'data' segment and may therefore only be loaded into writable memory.
However when dynamic drivers are converted to static drivers using co65 then that issue becomes a real problem as then the 'code' segment may end up in non-writable memory - and thus writing to the module header fails.
Instead of changing the way dynamic drivers work I opted to rather make static driver creation totally independent from dynamic drivers. This allows to place the module header in the 'data' segment (see 'module.mac').
After all it seems much cleaner to explicitly control the behaviour from the .travis.yml file than to behave differently "under the hood" when detecting a Travis CI build.
I must admit that I don't understand why but obviously it is necessary to place .PHONY below the definition of variables it refers to - although those variables are recursively expanded ones! Not doing so made libsrc/Makefile build only three target libraries.
Building the clean target in src or libsrc should only delete stuff created by the make in those directories. Having both separated allows the Travis CI build to replace the native binaries with cross built binaries while keeping everything else.
It seems more appropriate to trigger the inclusion of Makefile.inc via $TARGET (instead of $SRCDIR). This is btw. more consistent with extzp.s inclusion which is triggered via $TARGET too.
The 'install' target primarily aims to support pacaking tools. Therefore...
- It just presumes a "capable" install program to be present.
- There's intentionally no 'uninstall' target.
Originally I used the usual variables (like $(CC) and $(CFLAGS) ) but after
all this doesn't make sense as any predefined values and/or user defined
settings can only be wrong.
