Jeff King <p...@peff.net> writes: > I can easily replicate it here. > >> This seems due to the change in commit v1.7.12.4-1-g1226504: the >> issue is still present there, but no longer is in the preceding >> commit 7e201053 (a.k.a. v1.7.12.4). >> >> I haven't investigated this any further for the moment. > > Hmm. It looks like config.status depends on configure.ac. So make > rebuilds config.status, which runs "make configure", which includes > "config.mak.autogen", leading "make" to think that it should rebuild the > include file to make sure it is up to date. The include file depends on > "config.status", which needs to be rebuilt due to configure.ac, which > entails running "make configure", and so on.
I noticed this while looking at the other autoconf patch yesterday, but I was otherwise occupied in the evening and did not pursue it further. Thanks for looking into it. This may be an unrelated issue, but I've always thought that it was strange and extremely unintuitive that running "make configure" once only creates config.mak.autogen, while running it once again after that (i.e. while having config.mak.autogen in the tree) seems to run the resulting "./configure" as well. Maybe it is just me. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
