![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
jackRemoving code is good! But everywhere I've worked has had a "pile of makefiles" build system, which have invariably had problems when you remove a file, because the .d files are still hanging around, and make chokes on a source file because it doesn't have the headers it needed last time, even though they're actually not necessary to actually build the file.
And it's a matter of culture whether it's "when you check out code, you often need to make clean or make undepend somewhere to get it to compile" or "when you check in code, you need to find a workaround to make it build cleanly even if you've removed files".
Do people with more recent build tools than "make" avoid this problem?
However, after thinking it through carefully I eventually decided on one of the ways to makefiles cope with this correctly.
The trick
You still do "-include $(OBJ_FILES:%.c=%.d)" or equivalent.
But when you produce a .d file with gcc (usually as a side effect of producing a .o file via -MMD), add an extra line at the end of the recipe, a perl script which edits the .d file in-place and replaces each "filename.o: header1.h header2.h..." with "filename.o $(wildcard: header1.h header2.h...)"
That way, if any dependency has *changed* a rebuild is forced as normal. But only dependencies that actually exist become dependencies within the makefile. (Deleting a header file doesn't trigger a rebuild, but it doesn't with the old system either since the .o file already exists.)
I can share the exact script if anyone wants to see.
And it's a matter of culture whether it's "when you check out code, you often need to make clean or make undepend somewhere to get it to compile" or "when you check in code, you need to find a workaround to make it build cleanly even if you've removed files".
Do people with more recent build tools than "make" avoid this problem?
However, after thinking it through carefully I eventually decided on one of the ways to makefiles cope with this correctly.
The trick
You still do "-include $(OBJ_FILES:%.c=%.d)" or equivalent.
But when you produce a .d file with gcc (usually as a side effect of producing a .o file via -MMD), add an extra line at the end of the recipe, a perl script which edits the .d file in-place and replaces each "filename.o: header1.h header2.h..." with "filename.o $(wildcard: header1.h header2.h...)"
That way, if any dependency has *changed* a rebuild is forced as normal. But only dependencies that actually exist become dependencies within the makefile. (Deleting a header file doesn't trigger a rebuild, but it doesn't with the old system either since the .o file already exists.)
I can share the exact script if anyone wants to see.