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. >> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html