> The third, Build, will teach you about how to reliably build your software with Make.

Make? In 25 years as a professional developer I have never encountered make in the enterprise.

At least cover the various generic _models_ behind a few of the modern build tools so students can understand both the commonality and the differences between say NX, NPM, Maven, Gradle, go build etc.

Maybe a class on CI/CD pipelines, too.

I develop embedded software. I use make all the time.

I don't want to .. but people keep using it because it's simpler than other build systems.

Many UI tools based on eclipse use make under the hood.

Many recipes used by Yocto just use make to build the software and then install the output somewhere.

It all depends what you're trying to build and where you work.

You'll never guess what we talk about later on in the unit. Spoiler: exactly that!

It notionally focuses on make but the concepts apply much more broadly than the one specific tool

makefiles and shellscripts are still knocking around in systems programming world, which i think is the world OP comes from

Makefiles are a perfect abstraction over proprietary CI/CD DSLs and commands.

As a polyglot, having to remember and the difference is awful - so I make(ha!) local Makefiles that invoke the relevant tool, the same routine concepts (lint, build, or run tests) may be "yarn foo -arg1", "npx -foo", "go bar" depending on project and tool, which gets annoying when you're frequently switching between projects.

Big tech with monorepos solve this cognitive effort using a unified build system (blaze, buck, buck2). IMHO, Make makes a decent glue system at smaller organizations lacking a compiler/build/tooling team.

Indeed. CMake is now the gold standard for C/C++ projects. It should be taught especially in an introductory class.

I did, but so what? But make IS the generic model and no one should invent any kind of build system without understanding make first.