Consider replacing the .sh files in `build` using `make`

[jdhoffa]

or maybe just? (https://github.com/casey/just)

Benefits of using make:

• It automatically checks to see what is out of date, so as to build only what it needs to build (rather than always re-running the same build script)
• It performs a topological sort or some other tree analysis that determines what depends on what and in what order to build the out-of-date things such that every prerequisite is built before every dependency and only built once.
• It's a language for declarative programming. New elements can be added without requiring them to be merged into an imperative control flow.
• It contains an inference engine to process rules, patterns, and dates, and this, when combined with the rules in your particular Makefile, is what turns make into an expert system.
• It has a macro processor.

I'll be honest, I'm not entirely sure what the benefits of using just are. It seems to be a newer make that "tries to fix some annoying idiosyncracies. With just, you can easily make different recipes to build (different recipes for example to deploy, build for release or debug, run in debug-mode (or with logging enabled), test, lint, document, updating dependencies, and any other complex set of commands that you really should write down somewhere, if only to be able to remember them

[jdhoffa]

I have a feeling this is what we can/ should be looking into instead of docker-compose to handle our prod vs dev workflows and environments and all the details that go along with that. That said, I don't know a whole lot about this honestly.

@cjyetman @AlexAxthelm please feel free to comment on any of this. If you agree that it's interesting, I can have a look and draft a PR.

[cjyetman]

I'm not thrilled about the idea of replacing one thing we don't understand super well but it works with something else that we understand even less, but if you're willing to dig into it and figure it out and get it working and it doesn't require a lot of maintenance, then sure, why not? Not sure if or or how widely make is installed by default on various machines/OSs, so it may cause a new system dependency situation for any machine we want to use for development (might even be infeasible for Windows?).

[AlexAxthelm]

My big issues with using make is that our build process doesn't inherently create artifacts anymore. Maybe this would have been a reasonable idea when we were creating zips and sftping them over, but now that we're pushing to a container registry, we're not making anything that make can readily identify.

Brief explainer: make checks the target (which must be something that the OS recognizes as a file, with a path) either:

1. does not exist, or
2. exists, but the file modification time is older than any of its dependencies.

If a dependency also has a recipe in the makefile, then it recurses down, and checks everything there using the same process, until it has ensured that all of the dependencies are older than the (invoked) target.

So, since we aren't in the business of creating files anymore (docker images don't count, since there's not a friendly way to access them via the OS), I don't think make is the right tool for us here.

Addendum:

or maybe just? (https://github.com/casey/just)

This seems neat, but I don't want to introduce it as a dependency. make is a pain to get working correctly, but at least it's a well-known pain (read: easy to find answers for on StackOverflow)