You are not logged in

Looking at this again, the 3.82 output is the same as the 3.81 output and is correct. The reason is that when you add the explicit -include of Obj/test1.d that forces the target to be known to make, and make considers it to exist hence be a valid result of the vpath lookup.

The output you show here is actually the output you get when you use GNU make 3.81, not GNU make 3.82. And, this output is correct for the reasons I've described in response to your email to the bug-make mailing list.

However, your example does point out what appears to be a bug in GNU make 3.82. In 3.82 in a completely clean directory your makefile gives a different output; instead of succeeding it shows:

Looking at the debug and -p output, it seems that after we try and fail to build the Obj/test1.d file for the -include, somehow the prerequisite "test1.d" is changed to be Obj/test1.d which is wrong:

??!! Looking at the output of make -p for the above, I see:

??what?? Why is the prerequisite in the list here Obj/test1.d? It should just be test1.d.

So, although the original bug report is not valid (the makefile is not correct) and the example works as expected in GNU make 3.81, I'm leaving this open to track the unexpected behavior in GNU make 3.82.

Note: On Windows platform this case work properly.
On Linux it's work only if dependency files placed in current directory
and -include of dependency files written without $(addprefix ...).
Adding vpath %.d doesn't solve problem.