Disagree. I had to learn make for my first job. I found two ways to manage dependencies that are probably the most common, and the limitations. There really isn't a method that is perfect; I don't know if dependencies can be done (even outside of C) without occasionally rebuilding.
The methods that I've seen rely on using the compiler to generate .h dependencies via the preprocess command. This can be done with gcc / cygwin for cross compilation, or with the native compiler. I'll explain.
Method 1: the "better" method. Generate dependencies for your header files at make invocation, before compile step. This is more robust, but outside of very small projects, this can add a ton of time to the build.
Method 2: the faster, more common method. Generate dependencies as a side effect of the build. When you compile, you use the previous dependencies. A new dependency file is generated for next time.
They both have limitations. Method 2 can detect changes in the header files included from C files, but not headers included from H files. Method 2 can detect changes in header chain, but not all the time. I think it's the files that the headers include, those includes from that file don't get updated, but it's been a while since I've read the paper.
Anyway neither method is that hard. You use gcc to generate dependencies for each file, then combine into one file (or you may create
.d files, but for some reason a single file is common). That's it.Otherwise, add a step to compilation (some compilers may have a build in "byproduct" command). Every time you generate .c there's also .d. When you compile, you use the previous *.d file.
Yes you need to know make, and this is an intermediate-to-advanced make task, but this is true for any build system! Entry level is a user that usually just adapts a build from the engineer experienced with the build system.
