Historically $(OBJECTDIR) was created when Makefile.include is read. A
consequence is that combining "clean" with "all" (or any other build
target) results in an error because the clean removes the object
directory that is required to exist when building dependencies.
Creating $(OBJECTDIR) on-demand ensures it is present when needed.
Removed creation of $(OBJECTDIR) on initial read, and added an order-only
dependency forcing its creation all Makefile* rules where the target is
explicitly or implicitly in $(OBJECTDIR).
Relevant cc65 changes...
General:
- The compiler generates "extended" dependency info (like gcc) so there's no need for postprocessing whatsoever :-)
- The linker is very pernickety regarding the ordering of cmdline options so a custom linker rule is necessary :-(
Apple2:
- The various memory usage scenarios aren't specified anymore via separate linker configs but via defines overriding default values in the builtin linker config.
Atari:
- The builtin linker config allows to override the start addr so there no more need for a custom linker config.
- The C library comes with POSIX directory access. So there's no more need for for a custom coding.
CBM:
- The C library comes with POSIX directory access. So there's no more need for for a custom coding.
functions for converting between host and network byte order. These
names are the de facto standard names for this functionality because
of the original BSD TCP/IP implementation. But they cause problems for
uIP/Contiki: some platforms define these names themselves (Mac OS,
most notably), causing compilation problems for Contiki on those
platforms.
This commit changes all htons to uip_htons instead. Same goes for
htonl, ntohs, and ntohl. All-caps versions as well.
- cc65 2.13. allows to override the stacksize from the linker command line thus eliminating the need for linker configs maintained by Contiki.
- cc65 2.13. integrates the startup code with the library. In 2.12. the startup code pulled in main(). Now main() is supposed to pull in the startup code. But if main() resides itself in a library (as with Contiki) then nothing is pulled in at all :-(. The workaround is to pull in main() explicitly through the new option -u (working like the same GCC option).
The processing done in the canned command sequence FINALIZE_DEPENDENCY brings this tab character to the beginning of the line making the empty rule look like a command.
Therefore we replace the tab character in question with a blank.
At least with gcc (and cc65) the dependency files are generated without an additional run of the C compiler. This is especially beneficial on Cygwin because of the fork() performance issue.
