Re: [PATCH 2/3] Makefile: use `find` to determine static header dependencies

[Jeff King <peff@peff.net>]

On Mon, Aug 25, 2014 at 03:08:50PM -0700, Junio C Hamano wrote:

> Jonathan Nieder <jrnieder@gmail.com> writes:
> 
> >> Wouldn't it be sufficient to start digging not from "*" but from
> >> "??*"?
> >
> > Gah, the * was supposed to be . in my examples (though it doesn't
> > hurt).
> >
> >> 	find ??* \( -name Documentation -o -name .\?\* \) -prune -o -name \*.h
> >
> > Heh.  Yeah, that would work. ;-)
> 
> Continuing useless discussion...
> 
> Actually as you are not excluding CVS, RCS, etc., and using ??* as
> the starting point will exclude .git, .hg, etc. at the top, I think
> we can shorten it even further and say
> 
> 	find ??* -name Documentation -prune -o -name \*.h
> 
> or something.

I had originally considered starting with "find *", but I was worried
about shell globbing overflowing command-line limits here. "echo *" on a
built tree is about 12K. That's laughably small for Linux, but would
other systems (which, after all, are the main targets) be more picky?

POSIX lists 4K as the minimum, and that has to fit the environment, too.

I'd also be fine to try it and see if anybody on an antique system
complains.

> Don't we want to exclude contrib/ by the way?

Probably. For calculating dependencies, it is OK to be overly
conservative (the worst case is that we trigger a recompile if somebody
touched contrib/.../foo.h, which is rather unlikely).

For the .pot file, being conservative is a little annoying.  In theory
we might want to translate stuff in contrib/, but it probably is just
extra work for translators for not much benefit (though I have not
really used gettext; I assume it only pulls in strings marked with _()
and friends, so being conservative is maybe not that big a deal...).

In that sense, maybe we should just hit the whole tree to be on the
conservative side. The two reasons I did not in my initial attempt were:

  1. Performance. But with the final form, we only the run the `find` at
     all very rarely, so shaving off a few readdirs() is not that big a
     deal.

  2. There are a few problematic areas. t/perf may contain build trees
     which are copies of git, which I expect would confuse gettext.

So I dunno.

-Peff