Regarding the Makefile, I have a few primary suggestions right now. Most of them revolve around making the Makefile drastically simpler, following the theme of introducing new concepts incrementally.
[ ] Remove the SRCDIR variable. The point of variables like OBJDIR is to allow building out-of-tree in a flexible location; however, it makes imo no sense to allow pointing the Makefile at a different source tree, since it's inherently part of it.
[ ] Use ${} for variables instead of $(). This helps differentiate them from function calls (which only accept the latter syntax); this is especially useful when both kinds are nested.
[ ] Remove all of the *DIR and RGB* variables. For a "directed" project like this, it should be fine to hardcode all paths; this will notably remove one layer of indirection, and allow the reader to familiarise themselves with what that layer of indirection will "resolve" to. (There may be a case for keeping all of the RGB* variables, in case someone doesn't have RGBDS in their path, or under different names? Idk.)
[ ] Build in-tree. Building out-of-tree is better for a lot of reasons, but adds significant complexity (creating output directories, doing more path substitution instead of just extension rewriting, etc.). Again, since this is a "controlled environment", it should be fine to do things slightly dirty if it helps introducing concepts gradually; additionally, I believe experiencing the downsides of in-tree builds should help justify the extra complexity of out-of-tree builds when they're introduced later.
Continuing the discussion in https://github.com/gbdev/gb-asm-tutorial/pull/57:
@ISSOtm said:
Regarding the Makefile, I have a few primary suggestions right now. Most of them revolve around making the Makefile drastically simpler, following the theme of introducing new concepts incrementally.
SRCDIRvariable. The point of variables likeOBJDIRis to allow building out-of-tree in a flexible location; however, it makes imo no sense to allow pointing the Makefile at a different source tree, since it's inherently part of it.${}for variables instead of$(). This helps differentiate them from function calls (which only accept the latter syntax); this is especially useful when both kinds are nested.*DIRandRGB*variables. For a "directed" project like this, it should be fine to hardcode all paths; this will notably remove one layer of indirection, and allow the reader to familiarise themselves with what that layer of indirection will "resolve" to. (There may be a case for keeping all of theRGB*variables, in case someone doesn't have RGBDS in their path, or under different names? Idk.)