Re: Idea of triggering bugs in users' Makefiles

[Edward Welbourne]

David A. Wheeler (4 February 2022 17:43) wrote:
> For example: When running each recipe, enable tracing
> to note when files are opened for reading/writing.
> If a recipe opens a file for reading (or presence?), and
> that file isn't listed as a dependency but SHOULD be, warn about it.
> E.g., "Warning: Recipe for XYZ reads file ABC but
> this is not listed as a dependency". My heuristic:
> A file should be listed as a dependency if it's
> listed as a dependency in the makefile, is in the current
> directory or lower, or is in the home directory or lower AND
> is not hidden (its basename does not begin with ".").
> There would probably need to be some options to control
> what "should be listed as a dependency" beyond the default.

This may run into problems with automatically-generated dependencies.
Compilers can generate a .d file that encodes the dependences of a .o
file being compiled; it is common to include the generated .d files into
the make-file.  When the .o file doesn't exist, the .d file isn't
needed, as make knows to build it regardless of what it depends on,
provided it has a suitable source file and pattern rule to make it.  So
one of the natural optimisations is for the include of .d files to skip
those for any .o files that don't exist, rather than obliging make to
generate the .d files in a separate pre-compilation step, just so as to
include them, when doing this doesn't change the fact that the .o file
is known to be in need of building.

Thus, in a pristine build from scratch, it is entirely legitimate for
make to work with incomplete dependency information - as long as it
knows that it needs to build a file, and what recipe to use to do that,
it doesn't need to know chapter and verse about what it depends on aside
from its primary source file.

That doesn't mean the proposed check isn't possible; but it may limit
its usefulness to during a remake after the first build of a project.

        Eddy.