O(1) Build File

With Bazel for example, you typically have build files in each directory, and a test target for each test class in that build. But bazel allows you to select and run targets in a collection of directories, select targets recursively, or by a variety of other criteria. Your CI systems runs targets selected implicitly, while each build expresses the test targets explicitly.

Actually it doesn't really, but that is a cultural time bomb in our thinking that will catch up to us someday.

When you run cargo watch or nodemon with “debug”, you can comment out your “debug-command”, write a new one which immediately tests the part you’re cranking on, then the outer “make debug” test runner interface works exactly the same but runs a different order of the same tests so the new code fails quicker if there is an issue.

Definitely agree CI bloat control is crucial, just saying, if you go too “coarse grained” you’re unable to reshuffle the test chunks quite so easily for faster runs. Matters a lot less in Rust since the tests are quick, but in languages like Python, test order can make a huge difference for developer experience.

Some of those are specific to the historical way C projects work, and others I disagree with, but a lot are still useful and weren't mentioned in this link:

    build family:
        all - build everything, but don't run it (this is an important thing). GNU says this should be the default, but sometimes I have `make default` only compile the main program, whereas `make all` additionally compiles some maintainer-only helper programs and such (which might take longer).
        all-$FOO - for example, all-objects verifies that everything compiles without running the expensive linking step
        gen - build just generated files. Might have subtargets for non-distributed, distributed-but-not-committed, and committed files.
        docs - GNU names specific formats, but info is largely ignored by everyone else. Generating `man` pages may depend on building the program first (but beware cross builds ... should that mean such docs are committed!); other forms of documentation are generally unrelated to the main build but may rely on other tools (which must be built or even installed separately - beware versions generating different output!).
        dist - build a source tarball; note that this often includes generated files not committed to the repo. Generally we defer binary tarballs to the package manager these days, but historically a lot of C makefiles *not* from the GNU project also built those under some name.
    clean family:
        (each of these depends on the previous)
        mostlyclean - delete all but a few slow-to-build core libraries. This is probably mostly an artifact of poor dependency tracking, but not altogether useless in some form
        clean - delete all normally-built files. This concept remains useful because we don't like junk lying around. Compared to `distclean` this does not delete configuration; like distclean it isn't supposed to delete generated files if they are distributed.
        distclean - revert everything to exactly the state of the source distribution tarball (which, again, includes some generated files). People have kind of given up on this as a stated goal in favor of from-scratch builds but that doesn't mean the concept is useless.
        maintainer-clean - delete all generated files, even ones that were in the dist tarball. Many non-GNU projects don't distribute generated files (since nowadays we assume it is reasonable to have bison etc. installed), and thus don't distinguish between distclean and maintainer-clean.
        (using `git clean` is useful for the end user but is dangerous in scripts)
    introspection family:
        help - give a basic overview of what build targets are available
        list-$FOO - for things like "list what programs and libraries will be built", "list what tests are available" etc.