Re: [PATCHv3 02/11] Makefile: fold MISC_H into LIB_H

Hi,

I finally found some moments to revisit this series, so I'm starting
here.  I think the justification for this patch is something like
this:

  Keeping track of what files include each header is an error-prone
  chore.  On top of that, for l10n, these days we have to keep a master
  list of all headers, too, which is double work when adding a new
  header that adds insult to injury.

  Active Makefile hackers tend to use compilers like gcc that support
  automatic dependency generation with -MMD.  The precise header deps
  aren't even used when building with these compilers, so the people
  maintaining the precise header deps do not benefit from them at all.
  Unfair!

  Non-developers who can't fend for themselves do not rebuild after a
  small header change very often, so they would not be hurt much by a
  "change one header, rebuild everything" rule when automatic
  dependency generation is disabled, either.

  That leaves at least one important category of people to be hurt by
  this change: the glorious MSVC hackers.  MSVC supports the
  appropriate magic to compute header dependencies, but no one's
  gotten around to teaching the Makefile to use it yet.  So let's stop
  delaying the inevitable and drop the detailed dependencies.  If
  anyone complains then we can work with them to finish support for
  computing header dependencies for the relevant compiler.

Fair enough.  

Two details puzzle me:

Jeff King wrote:

                                The original point
of LIB_H was that it would force recompilation of C files
when any of the library headers changed.

LIB_H was introduced by commit e590d694 (Add more header dependencies,
2005-04-18).  It only lists

	cache.h
	object.h

even though some translation units included tree.h, commit.h, or
blob.h already.  So at least back then, it seems to have been about
library headers and not about all headers (and "all headers" was
puzzlingly not worth worrying about at all).

So isn't this a fundamentally new thing, rather than a return to the
state of nature?

The other remaining question is why we don't use something like
$(wildcard *.h) and avoid listing individual headers altogether.
Is the fear that some stray non-git header will find its way into
the cwd and poison the translation files?  (If so, I'd like to
document that as well to help readers understand why we keep doing
the work we do.)

Ciao,
Jonathan