Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SHMUP: Restructure Makefile #64

Open
4 tasks
avivace opened this issue Aug 27, 2023 · 0 comments
Open
4 tasks

SHMUP: Restructure Makefile #64

avivace opened this issue Aug 27, 2023 · 0 comments
Assignees

Comments

@avivace
Copy link
Member

avivace commented Aug 27, 2023

Continuing the discussion in #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.

  • 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants