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

[Paul D. Smith]

Follow-up Comment #9, bug #61226 (project make):

For now I decided to put back the original behavior (revert the main.c
changes).  I will leave this issue open to think about how to best introduce a
backward-incompatible change that might help in this situation.

I really don't like the idea of creating a distinction between an "empty"
recipe and a "non-empty" recipe.  Just to point out the description in "Rules
without Recipes or Prerequisites" is talking about *NO* recipe vs. some
recipe, not empty recipe vs non-empty recipe.  That is, the difference between
*FORCE:* and *FORCE:;*.  However as I mentioned before it's not actually
required that you don't have a recipe here: any recipe (or no recipe) that
doesn't update the target will serve just as well.  This text is not wrong,
although it could be argued that it's incomplete by not describing all the
other ways a target might be considered up to date in addition to a missing
recipe.

The text in "Including Other Makefiles" was confusing so I modified it to say
this:

> Only after it has failed to find a rule to remake the makefile, or it found
a rule but the recipe failed, will @code{make} diagnose the missing makefile
as a fatal error.


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Alejandro Colomar (man-pages)]

On 10/26/21 3:20 PM, Alejandro Colomar (man-pages) wrote:

Hi Paul and Dmitry,

On 10/26/21 1:16 AM, Paul Smith wrote:

On Mon, 2021-10-25 at 17:51 -0400, Dmitry Goncharov via Bug reports and
discussion for GNU make wrote:

On Monday, October 25, 2021, Alejandro Colomar (man-pages) <
alx.manpa...@gmail.com> wrote:

Why do I do this?  Because, if you remove a file from your tree, an
old .d file will require that file and make your build fail,
requiring you to clean before making again.


This has been solved long ago. Check the awesome advanced dependency
generation article by Paul.


FYI:

   
http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/


The issue you raise (as well as others) is discussed, hopefully
clearly, in this article [*].


[*] 
http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/#depdelete 





Thanks for sharing that great article!

I'll definitely have to have a look at many or all of the articles in 
that website!


I've already applied some of the improvements there, reducing no-op make 
times to 0.7 s in single-process and 0.35 with 'make -j'.  I'll keep 
adding the other improvements too.


In the end, I couldn't use all of the features that the article shows.

Since I do a lot of static analysis to the files, I also have 
*.checkpatch.touch (and similar) targets created in the dependencies 
files, and since those tools can't generate dependencies files as side 
effects, I need an explicit rule for creating them.  Otherwise, if I 
create all of them at the compilation stage, it is very likely that at 
some point I only run static analysis and not compilation, and I'll have 
outdated dependencies files the next time I run static analysis, and I 
won't notice.


Maybe I could overcome this with some complicated workaround, but I 
don't think it's worth it: 0.7 s is already a very acceptable time :-) 
And it would probably be a bit obscure and maybe slower for full builds.


So I'm forced to create dependencies files not as side effects, but as 
real targets:



DEPTARGETS = -MT $<.checkpatch.touch -MT $<.clang-tidy.touch \
 -MT $<.cppcheck.touch -MT $<.cpplint.touch
DEPHTARGETS = $(DEPTARGETS) -MT $<.gch
DEPCTARGETS = $(DEPTARGETS) -MT $(builddir_)/$*.i
$(UNITS_h_d):   $(builddir)/%.d: $(INCLUDEDIR)/% $(mk) | $$(@D)/.
$(CC)  $(CFLAGS)   -I $(INCLUDEDIR) -M -MP $(DEPHTARGETS) -MF $@ $<
$(UNITS_hxx_d): $(builddir)/%.d: $(INCLUDEDIR)/% $(mk) | $$(@D)/.
$(CXX) $(CXXFLAGS) -I $(INCLUDEDIR) -M -MP $(DEPHTARGETS) -MF $@ $<

$(UNITS_c_d):   $(builddir_)/%.d: $(SRCDIR)/% $(mk) | $$(@D)/.
$(CC)  $(CFLAGS)   -I $(INCLUDEDIR) -M -MP $(DEPCTARGETS) -MF $@ $<
$(UNITS_cxx_d): $(builddir_)/%.d: $(SRCDIR)/% $(mk) | $$(@D)/.
$(CXX) $(CXXFLAGS) -I $(INCLUDEDIR) -M -MP $(DEPCTARGETS) -MF $@ $<





Thanks!

Alex



Cheers,

Alex





--
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/

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

[Alejandro Colomar (man-pages)]

Hi Paul and Dmitry,

On 10/26/21 1:16 AM, Paul Smith wrote:

On Mon, 2021-10-25 at 17:51 -0400, Dmitry Goncharov via Bug reports and
discussion for GNU make wrote:

On Monday, October 25, 2021, Alejandro Colomar (man-pages) <
alx.manpa...@gmail.com> wrote:

Why do I do this?  Because, if you remove a file from your tree, an
old .d file will require that file and make your build fail,
requiring you to clean before making again.


This has been solved long ago. Check the awesome advanced dependency
generation article by Paul.


FYI:

   http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/

The issue you raise (as well as others) is discussed, hopefully
clearly, in this article [*].


[*] 
http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/#depdelete



Thanks for sharing that great article!

I'll definitely have to have a look at many or all of the articles in 
that website!


I've already applied some of the improvements there, reducing no-op make 
times to 0.7 s in single-process and 0.35 with 'make -j'.  I'll keep 
adding the other improvements too.


Cheers,

Alex


--
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/

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

[Paul Smith]

On Mon, 2021-10-25 at 17:51 -0400, Dmitry Goncharov via Bug reports and
discussion for GNU make wrote:
> On Monday, October 25, 2021, Alejandro Colomar (man-pages) <
> alx.manpa...@gmail.com> wrote:
> > Why do I do this?  Because, if you remove a file from your tree, an
> > old .d file will require that file and make your build fail,
> > requiring you to clean before making again.
> 
> This has been solved long ago. Check the awesome advanced dependency
> generation article by Paul. 

FYI:

  http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/

The issue you raise (as well as others) is discussed, hopefully
clearly, in this article [*].


[*] 
http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/#depdelete

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

[Dmitry Goncharov via Bug reports and discussion for GNU make]

On Monday, October 25, 2021, Alejandro Colomar (man-pages) <
alx.manpa...@gmail.com> wrote:

> However, there's a downside to this:  The payment for this robustness is a
> non-negligible time cost.  The single-process time for a no-op make is
> around 10 s


>
>  10s is about 100 to 1000 times longer than what make is capable of.

Regards, Dmitry

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

[Dmitry Goncharov via Bug reports and discussion for GNU make]

On Monday, October 25, 2021, Alejandro Colomar (man-pages) <
alx.manpa...@gmail.com> wrote:
>
>
> Why do I do this?  Because, if you remove a file from your tree, an old .d
> file will require that file and make your build fail, requiring you to
> clean before making again.
>
>

This has been solved long ago. Check the awesome advanced dependency
generation article by Paul.

Regards, Dmitry

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

[Alejandro Colomar (man-pages)]

Hi all,

Regarding the generation of .d files, I may be a bit paranoid, but I 
like to regenerate them unconditionally at the beginning of every make 
invocation.  I wouldn't trust on .d from my last build, since they may 
be outdated.


Why do I do this?  Because, if you remove a file from your tree, an old 
.d file will require that file and make your build fail, requiring you 
to clean before making again.


To be more precise, consider the following case:

old tree:

//foo.h
int a;

//foobar.h
#include "foo.h"

//unchanged.h
#include "foobar.h"


new tree:

//bar.h
int a;

//foobar.h
#include "bar.h"

//unchanged.h
#include "foobar.h"


foobar.d (or foobar.h.d, depending on your naming conventions) will 
state that foobar.h depends on foo.h, which doesn't exist anymore, and 
thus the build will fail.


My build system works no matter what, since it always has the latest 
dependencies list.  I don't even remember the last time that I had to do 
a 'make clean'.  I've only done recently at some points, to test the 
Makefile itself, but not because I needed it.


See part of my Makefile implementation below, if you're interested in it.

However, there's a downside to this:  The payment for this robustness is 
a non-negligible time cost.  The single-process time for a no-op make is 
around 10 s (i.e., if I run 2 consecutive makes, the second will take 10 
seconds no matter what).  I can reduce that to 1.5 s with 'make -j', but 
it's still a considerable overhead.  But, considering that a full 
project build is around 10 minutes, I can assume that.


To have an idea of the overhead compared to the project size, here are 
some numbers of the library to which those correspond:


$ sloccount include/ src/
[...]
SLOCDirectory   SLOC-by-Language (Sorted)
14322   src ansic=11812,cpp=2510
9237include ansic=9237
[...]
 generated using David A. Wheeler's 'SLOCCount'.

$ find include/ src/ -type f | wc -l
720

Cheers,

Alex


---

[...]

UNITS_c   := $(sort $(shell find $(SRCDIR_m) -type f | grep '\.c$$'))
UNITS_cxx := $(sort $(shell find $(SRCDIR_m) -type f | grep '\.cxx$$'))
UNITS_h   := $(sort $(shell find $(INCLUDEDIR__m)/ -type f | grep '\.h$$'))
UNITS_hxx := $(sort $(shell find $(INCLUDEDIR__m)/ -type f | grep 
'\.hxx$$'))
UNITS_src := $(patsubst $(SRCDIR_m)/%, $(builddir__m)/%, $(UNITS_c) 
$(UNITS_cxx))


[...]

UNITS_c_d   := $(addsuffix .d,$(filter %.c,$(UNITS_src)))
UNITS_cxx_d := $(addsuffix .d,$(filter %.cxx,$(UNITS_src)))
UNITS_h_d   := $(patsubst $(INCLUDEDIR)/%, $(builddir)/%.d, $(UNITS_h))
UNITS_hxx_d := $(patsubst $(INCLUDEDIR)/%, $(builddir)/%.d, $(UNITS_hxx))
UNITS_d := $(UNITS_c_d) $(UNITS_cxx_d) $(UNITS_h_d) $(UNITS_hxx_d)

[...]

.PHONY: $(UNITS_d)
$(UNITS_h_d):   $(builddir)/%.d: $(INCLUDEDIR)/% Makefile | $$(@D)/.
$(CC)  $(CFLAGS)   -I $(INCLUDEDIR) -M -MT $<.gch -MF $@ $<
$(UNITS_hxx_d): $(builddir)/%.d: $(INCLUDEDIR)/% Makefile | $$(@D)/.
$(CXX) $(CXXFLAGS) -I $(INCLUDEDIR) -M -MT $<.gch -MF $@ $<

$(UNITS_c_d):   $(builddir_)/%.d: $(SRCDIR)/% Makefile | $$(@D)/.
$(CC)  $(CFLAGS)   -I $(INCLUDEDIR) -M -MT $(builddir_)/$*.i -MF $@ $<
$(UNITS_cxx_d): $(builddir_)/%.d: $(SRCDIR)/% Makefile | $$(@D)/.
$(CXX) $(CXXFLAGS) -I $(INCLUDEDIR) -M -MT $(builddir_)/$*.i -MF $@ $<

[...]

include $(UNITS_d)


--
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/

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

[Dmitry Goncharov via Bug reports and discussion for GNU make]

On Sun, Oct 17, 2021 at 11:17 PM Britton Kerin  wrote:
> I got that but it sounds like the proposal is for it to do one thing
> if the file is a .d and otherwise something else?

The proposal is to see if the recipe is empty.

There is this statement in the manual
"If a rule has no prerequisites or recipe, and the target of the rule
is a nonexistent file, then make imagines this target to have been
updated whenever its rule is run."
It is not clear how this behavior could be implemented without
checking the recipe.

regards, Dmitry

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

[Dmitry Goncharov via Bug reports and discussion for GNU make]

On Mon, Oct 25, 2021 at 6:12 AM Edward Welbourne  wrote:

> Surely that would solve your problem, without invasive surgery in GNU
> make, or special-case handling of .d files anywhere but your make file ?

Actually, my makefiles do not suffer from this. i use the technique
described here 
https://github.com/dgoncharov/fun/blob/master/autodeps/include_as_part_of_the_dag,
which avoids including .d files.
makefiles which include .d files suffer.


regards, Dmitry

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

[Paul Smith]

On Mon, 2021-10-25 at 10:11 +, Edward Welbourne wrote:
> Dmitry Goncharov (17 October 2021 18:33) wrote:
> > 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.
> ...
> 
> Surely that would solve your problem, without invasive surgery in GNU
> make, or special-case handling of .d files anywhere but your make
> file ?

Two points:

First for Eddy's response: the issue we are thinking about isn't how
one person could rewrite makefiles to work differently: the issue is
that a somewhat serious backward compatibility break has been
introduced that could break thousands of makefiles, and we have to
resolve that before the next release.

Second for Britton's response: as far as I can tell no one is
suggesting that make would check the name of an included file and if it
ended in ".d" make would behave differently in some way than if it were
named ".od" or whatever.  Certainly I hope we all agree that kind of
check is not appropriate.  If you check his patch you'll see the change
Dmitry proposed was different: it didn't check the name of the target,
it checked to see if the recipe of the target was empty.  That is, it
would distinguish between this:

   include foo.xx
   foo.xx:

and this:

   include foo.xx
   foo.xx: ; : nothing

In both cases "foo.xx" is not created but (with Dmitry's change) the
first case would not give an error while the second one would give an
error, because it has a recipe.

The _name_ of the target is irrelevant.

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

[Edward Welbourne]

Dmitry Goncharov (17 October 2021 18:33) wrote:
> 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.

Given that I always generated .d files as side-effects of generating .o
files, a missing .d file always meant the .o was missing, so my make
files didn't need to know what the .o file depended on, aside from its
primary source file, so I just used

include $(wildcard $(OBJECTS:%.o=%.d))

Surely that would solve your problem, without invasive surgery in GNU
make, or special-case handling of .d files anywhere but your make file ?

Eddy.

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

[Britton Kerin]

On Sun, Oct 17, 2021 at 4:44 PM Dmitry Goncharov
 wrote:
>
> On Sun, Oct 17, 2021 at 3:05 PM Britton Kerin  wrote:
>
> > If I understand right that the idea is a special case for .d files
>
> The question being discussed is what to do when make cannot include a 
> makefile.

I got that but it sounds like the proposal is for it to do one thing
if the file is a .d and otherwise something else?

Britton

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

[Dmitry Goncharov via Bug reports and discussion for GNU make]

On Sun, Oct 17, 2021 at 3:05 PM Britton Kerin  wrote:

> If I understand right that the idea is a special case for .d files

The question being discussed is what to do when make cannot include a makefile.

regards, Dmitry

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
 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

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

[Dmitry Goncharov]

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:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Paul D. Smith]

Follow-up Comment #7, bug #61226 (project make):

Well, we could print one warning per include line rather than one warning per
file included.  Obviously, that warning would only talk about the first file
on the include line but since the suggested solution is to use "-include"
maybe that's sufficient.

> 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? 
Either the user wants the include to fail if the file doesn't exist in which
case they use "include" and get an error, or the user wants the include to not
fail if the file doesn't exist, in which case they use "-include" and don't
get an error which is presumably what they wanted.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Dmitry Goncharov]

Follow-up Comment #6, bug #61226 (project make):

It is disturbing that the warning is printed each time a .d file is missing.
In other words, make prints a warning in an everything goes as planned
situation, like a clean build. Switching to -include robs the user of a useful
message, should there be a real issue.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Dmitry Goncharov]

Additional Item Attachment, bug #61226 (project make):

File name: sv_61226_no_build_on_missing_includes.diff Size:1 KB
   




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Dmitry Goncharov]

Follow-up Comment #5, bug #61226 (project make):

> When you say the special behavior do you mean the section "Rules without
Recipes or Prerequisites"?

exactly


> I think that text is a little misleading.  There's actually nothing magical
about having no recipe or an empty recipe here, as best as I can remember. 
Make doesn't check for this.  Even if you provide a recipe for a force target
it will still behave the same as it would without a recipe, as long as the
recipe doesn't actually create the force target.

There is a difference between the implementation and the text in the manual.
Given that the implementation is bound by backward compatibility, i think the
text needs to be updated. Even though, this may not be what the original
authors intended.

There is also this statement in "3.3 Including Other Makefiles"
"...after it has tried to find a way to remake a makefile and failed, will
make diagnose the missing makefile as a fatal error. "

This statement says a missing makefile is a fatal error, regardless of whether
the rule returned success. Looks like this part of the manual needs to be
updated too.

> My current thinking on this is we should revert this part of the fix, but
leave the original part.

Do you mean keep the change in remake.c?

> Maybe the thing to do is, if we detect this situation we can emit a warning
message that users should change their makefiles to use "-include" instead of
"include" which would avoid that warning.  Then in a few releases we could put
back this change where make would fail if included files weren't built.

i am attaching another patch with a warning. If this patch is good, then we'll
need to update the tests.
This warning in the attached patch is quite verbose, because it is printed for
every missing .d file.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Paul D. Smith]

Follow-up Comment #4, bug #61226 (project make):

When you say the special behavior do you mean the section "Rules without
Recipes or Prerequisites"?

I think that text is a little misleading.  There's actually nothing magical
about having no recipe or an empty recipe here, as best as I can remember. 
Make doesn't check for this.  Even if you provide a recipe for a force target
it will still behave the same as it would without a recipe, as long as the
recipe doesn't actually create the force target.

So, I think the change to fail includes if the target doesn't actually build
them, only if it has a recipe, is too large of a backward-compatibility break
to consider for now.

My current thinking on this is we should revert this part of the fix, but
leave the original part.  Maybe the thing to do is, if we detect this
situation we can emit a warning message that users should change their
makefiles to use "-include" instead of "include" which would avoid that
warning.  Then in a few releases we could put back this change where make
would fail if included files weren't built.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Dmitry Goncharov]

Follow-up Comment #3, bug #61226 (project make):

i agree, this is a special case.
imo, empty vs not empty is okay for make to consider, given that make manual
documents this special behavior when the recipe or prerequisites are empty and
the file is missing.

This is in sharp contract with the other case, when there is a recipe and the
recipe fails to create the file. imo, it is correct for make to fail that
case.

Would it be acceptable if we could retain the previous fix and allow for this
special case?

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Paul D. Smith]

Follow-up Comment #2, bug #61226 (project make):

Hm.  I'm not a fan of this solution.  I really don't like having make do
different things depending on the content of recipes, even empty vs. not
empty.

Additionally, this is just a special case; it could be the case that we need
to actually have some recipe invoked, but then the recipe decides that there
is nothing to do for some reason and doesn't create the file.  One simple
example is that some makefiles use the shell no-op target ":" rather than an
empty recipe, just to be more clear about what's happening; like this:


hello.d: ; @:


If we don't consider, for the moment, backward compatibility, would it be more
correct and work properly to suggest that people should use -include in
situations where they don't want an error if the included file is not actually
rebuilt?


hello.o: hello.d; touch $@ $<
hello.d:;
-include hello.d


Of course even if this is the best answer it's not acceptable from a
backward-compatibility standpoint to break this common usage, at least not
immediately.  I think perhaps at least some of the change in the previous fix
might need to be reverted, although I'm not sure the entire thing needs to be.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Dmitry Goncharov]

Follow-up Comment #1, bug #61226 (project make):

This is an example of the failure

$ ls
makefile
$ cat makefile 
hello.o: hello.d; touch $@ $<
hello.d:;
include hello.d
$ make
makefile:3: hello.d: No such file or directory
$ echo $?
2


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Dmitry Goncharov]

Additional Item Attachment, bug #61226 (project make):

File name: sv_61226_no_build_on_missing_includes.diff Size:2 KB
   


File name: sv_61226_no_build_on_missing_includes_test.diff Size:3 KB
   




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Dmitry Goncharov]

URL:
  

 Summary: A regression prevents generation of missing included
dependency files.
 Project: make
Submitted by: dgoncharov
Submitted on: Sun 26 Sep 2021 02:34:37 PM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

7c4e6b0299774280e3a93060c70c661f459aaf40 introduced a change in main.c, among
others.
This change causes make to exit with an error message when a rule that matches
an included file does not create the file.
This change is good when the included file is indeed intended to be created.
However, this change is a regression when the included file is not intended to
be created, as in the case of generated dependency files.
E.g.


hello.o: hello.d; touch $@ $<
hello.d:;
include hello.d


In this makefile the rule 'hello.d:;' is not intended to create 'hello.d'.
Instead, when 'hello.d' is missing make runs 'hello.d:;' rule and imagines
'hello.d' was updated and then proceeds to create 'hello.o' and thus generates
'hello.d' as a byproduct of 'hello.o' generation.




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/