autogenerated dependency files are not being utilized properly

autogenerated dependency files are not being utilized properly

TL;DR
Acked-by: Mike Frysinger <vapier@gentoo.org>
=====

Auto-generated dependency rules are not being written correctly, so
changes to dependent files (e.g., headers) do not actually trigger
rebuilds.

The problem
===========

It appears that when a dependency generation flag is passed directly to
the preprocessor (with '-Wp,...'), it loses information about the output
path. So, it just makes up the output name as $(basename).o, with no
path information. This yields .*.c.dep files that look like this:

  flash_lock.o: flash_lock.c /usr/include/stdc-predef.h flash_unlock.c \
   (...)

and

  nanddump.o: nanddump.c /usr/include/stdc-predef.h /usr/include/ctype.h \
   (...)
   include/libmtd.h

This is the case for both in-tree *and* out-of-tree builds. Naturally,
this is a problem for out-of-tree builds. But it is also a problem for
in-tree builds, because we use rules like this for builds:

  $(BUILDDIR)/%.o: %.c

and make doesn't recognize $(BUILDDIR)/%.o as the same as %.o even when
$(BUILDDIR) == $(PWD).

Example failures
================

  ## Rebuilding after touching common header doesn't recompile anything
  $ make
  (...)
  $ touch include/libmtd.h
  $ make
    CHK     include/version.h

  ## Same for out-of-tree builds
  $ BUILDDIR=test make
  (...)
  $ touch include/libmtd.h
  $ BUILDDIR=test make
    CHK     include/version.h

I noticed this when seeing that flash_lock would not get rebuilt when
modifying flash_unlock.c (where 99% of the source code lies):

  $ make
  (...)
  $ touch flash_unlock.c
  $ make
    CHK     include/version.h
    CC      flash_unlock.o
    LD      flash_unlock

The fix
=======

Just pass -MD straight to the compiler, and make sure to specify the
output file for the dependency info with -MF.

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>