Make, as arcane as a build tool can be, may still be a good first fit for certain scenarios. Let's see how to make a build more palatable in this day and age if you choose this tool.
Nice, but only useful with plain old Unix Make, or maybe plain old GNU Make.
It's not much "help" for advanced make programs like BSD Make (or GNU Make where projects supply their own advanced macro packages) where the majority of targets are defined in the system-supplied macro package.
Also note that the "-l" option for "column" is non-standard. Better to use a special column separator character, such as a tab, to make it more portable.
BTW I had trouble with the basic REs in the sed expressions on NetBSD -- I just converted everything to full REs and used "sed -E" instead.
You could extend the grep to cover "known includes" to find system-supplied targets, or you could write a script to automatically traverse includes, or maybe encode the metadata in variables (instead of comments) so that you could extract it programmatically. Anyway, I didn't need any of that so I didn't go that route :) And if I needed such complexity, I'd start questioning whether using Make was a good idea in the first place!
Noted about the "column" comment. It is the first time I used it so didn't know that.
Because the way it tracks dependencies is insufficient to do a good job. You'll find yourself having to do "make clean" at odd times and start over to fix random build breakage. And you won't get as much build performance as you'd like.
Nice, but only useful with plain old Unix Make, or maybe plain old GNU Make.
It's not much "help" for advanced make programs like BSD Make (or GNU Make where projects supply their own advanced macro packages) where the majority of targets are defined in the system-supplied macro package.
Also note that the "-l" option for "column" is non-standard. Better to use a special column separator character, such as a tab, to make it more portable.
BTW I had trouble with the basic REs in the sed expressions on NetBSD -- I just converted everything to full REs and used "sed -E" instead.
You could extend the grep to cover "known includes" to find system-supplied targets, or you could write a script to automatically traverse includes, or maybe encode the metadata in variables (instead of comments) so that you could extract it programmatically. Anyway, I didn't need any of that so I didn't go that route :) And if I needed such complexity, I'd start questioning whether using Make was a good idea in the first place!
Noted about the "column" comment. It is the first time I used it so didn't know that.
"but please don’t use Make for new projects if you can avoid it!"
Why not? I've been recently learning it and I think its great for my purposes
Because the way it tracks dependencies is insufficient to do a good job. You'll find yourself having to do "make clean" at odd times and start over to fix random build breakage. And you won't get as much build performance as you'd like.
Here is something I wrote a while back on how better build systems just don't run into this issue: https://jmmv.dev/2020/12/google-no-clean-builds.html