On Sun, Oct 17, 2021 at 8:33 AM Dmitry Goncharov <invalid.nore...@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
