Thread (49 messages) flat view 49 messages, 4 authors, 2016-06-15

Re: [PATCHv2 1/8] Makefile: apply dependencies consistently to sparse/asm targets

From: Jonathan Nieder <hidden>
Date: 2016-06-15 22:54:09

Possibly related (same subject, not in this thread)

Jeff King wrote:
I just assumed that people who are actively hacking on individual header
files in git actually have a compiler that can do COMPUTE_HEADER_DEPENDENCIES.
That's probably true.  And it is presumably possible to implement
COMPUTE_HEADER_DEPENDENCIES for Solaris cc and MSVC, so people using
those compilers would just have an incentive to do that sooner.

So it's not all that bad.
Maybe that is not the case. If it were such a big deal, then why is
everything in LIB_H? Why don't people use these manual rules, or convert
existing LIB_H entries to use them?
Once a header is included by cache.h (like most headers in LIB_H),
there is not much hope for avoiding recompilations when it changes.
For people who are not actively hacking on header files in git, the
arguments from that patch apply (namely that LIB_H is so gigantic that
you are unlikely to hit a specific change where one of the few manual
rules is triggered, but LIB_H is not).
Unless they are bisecting, it would not be so bad for such people to
effectively have to run "make clean" between compiles, as you've
hinted.  They are not the people it is possible to easily improve
build performance for.
quoted
On the other hand, if someone were proposing adding a simple awk
script to implement a "make dep" fallback, I would understand that.
I'd be OK with that. Do you have one in mind, or do we need to write it
from scratch? Surely somebody else has solved this problem before.
There are lots of "make dep" implementations out there, but it's hard
to care enough to choose between them. :)  No one who actually doesn't
use gcc has spoken up as caring.  So if we're really feeling the pain
of maintaining the detailed COMPUTE_HEADER_DEPENDENCIES=no fallback
dependencies, let's just say so and drop them like you've suggested.

Before I thought you were saying "nobody is going to notice".  And I'm
pretty sure that's not true.  What I missed before is that a different
statement holds, namely "sure, some people will notice, but they have
an easy way to move forward and the outcome would be much better than
the status quo".

Sorry to be so dense before.

Jonathan
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help