[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug #61226] A regression prevents generation of missing included de

From: Britton Kerin
Subject: Re: [bug #61226] A regression prevents generation of missing included dependency files.
Date: Sun, 17 Oct 2021 11:04:17 -0800

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]