bug-make
[Top][All Lists]
Advanced

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

[bug #61226] A regression prevents generation of missing included depend


From: Dmitry Goncharov
Subject: [bug #61226] A regression prevents generation of missing included dependency files.
Date: Sun, 17 Oct 2021 12:33:04 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

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/




reply via email to

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