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. 3. Modify the change in main.c to print a warning and continue. i like option 2, which is what the first patch does. You correctly observed that this will break any rule that has prerequisites and a recipe and fails to generate the file and returns 0. This boils down to that difference between the implementation and the manual. Do you want to update the manual to match the implementation or vice versa? _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?61226> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/