On 2025-10-20 16:42, Yclept Nemo wrote: > Yes I agree with both Basile & Kaz. It was very simple to switch to > tracking a list of sources. In the future I will simply be sure to select a > more modern version of make.
By the way, in makefiles it is a better practice to track the list of object files rather than sources. If you are used to IDE tools and whatnot, your intuition may deceive you into thinking that a Makefile is like a project file where you declare the things that you are writing yourself, your sources. This is false! What you declare to the makefile is that you are building a certain program: your top target. (Or library or whatever). Now the problem is that the pieces that go into the program cannot be inferred. What goes into the program is some .o files. Those do not exist; they have to be built. There is no way to know what they are, so those are what you declare: OBJS := parser.o lexer.o main.o typecheck.o lib.o cool-lang: $(OBJS) OBJS is maintained by hand. Once you have declared the objects dependencies, make can infer the sources. Oh, we need a parser.o? Hmm, what can that be made out of. Let's try various suffixes instead of .o. Oh look there is a parser.c; that must be it. And so the built-in pattern rule for %.o: %.c kicks in for this inferred prerequisite. If you're using GCC, you can override the rule with one that generates dependency info in addition to dropping .o files. (And as we discussed, some older makes like 3.82 are missing some magic to make that 100% perfect in the face of deleted header files, but would that be deal breaker for just supporting a platform which still relies on 15 year old make?)
