Re: [bug #61226] A regression prevents generation of missing included dependency files.

[Britton Kerin]

On Sun, Oct 17, 2021 at 8:33 AM Dmitry Goncharov
<INVALID.NOREPLY@gnu.org> wrote:
>
> Follow-up Comment #8, bug #61226 (project make):
>
> > > Switching to -include robs the user of a useful message, should there be a
> real issue.
>
> > I'm not sure what this means: in what situation do we lose a useful
> message?
>
> -include robs the user of a not readable or corrupted .d file, even though
> user's intervention is required.
>
> i think, hand written included makefiles require different error handling than
> generated .d files.
>
> A missing hand written makefile is an error. The user has the choice of
> 'include' vs '-include' as you described above. I agree with that logic.
>
> On the other hand, a missing .d file (or any other included makefile generated
> by a rule) is not an error. It is simply a clean build.
>
> i think, make should not print a warning when a .d file is missing. make
> should proceed and create the missing file. However, when .d is present, but
> make cannot include it, then make should print an error and stop.
>
>
> The traditional make behavior, which is still in 4.3 is exactly this.
> i think, we should retain this behavior.
>
>
> in regards to the change in main.c see the following possibilities
>
> 1. Revert the change in main.c.
> 2. Modify the change in main.c to allow for missing .d files, but print an
> error and stop in the other cases.

If I understand right that the idea is a special case for .d files I
dislike this sort of thing in make.  All the various C-centric rules
etc. I tend to just disable even when building C, and this sounds
worse because it's not just a disableable library.

Admittedly I haven't used the generated dependency files in a while
but if some additional semantics are needed to support them well I'd
prefer it be exposed as a general feature rather than hidden.  This
might add a bit of interface  complexity but that's still better
hidden special case behavior IMO.

Britton