On Thu, Jul 22 2021, Junio C Hamano wrote: > Taylor Blau <me@xxxxxxxxxxxx> writes: > >>> > cscope.out: $(FOUND_SOURCE_FILES) >>> > - $(QUIET_GEN)$(RM) cscope* && \ >>> > - echo $(FOUND_SOURCE_FILES) | xargs cscope -b >>> > + $(QUIET_GEN)$(RM) cscope.out && \ >>> > + echo $(FOUND_SOURCE_FILES) | xargs cscope -f$@ -b >> >> But that alone is a good change in my mind at least. Then it's clear >> that that target is responsible for generating cscope.out and nothing >> else. > > Probably. The preparatory $(RM) is close enough to the invocation > of cscope that anybody adding other options like '-q' should be > careful enough to notice that the line needs to be touched, too, so > I can be talked into thinking that $(RM) change here is a good one. > I do not know about "-f$@", which is "Meh" to me. Is there a good > reason to suspect that they might want to change the default output > filename? > >> So I'd be in favor of rewording the patch message and only retaining >> this hunk (and dropping the other two). > > Yup. I do not mind dropping one half of this hunk, too, but again, > I do not mind keeping -f$@, either [*1*]. > > > [Footnote] > > *1* if the patch to add cscope support anew were done with -f$@, I > wouldn't have insisted removing it, out of the principle "any Meh > change is not worth applying once the code was written and > working". As long as we have no user of a -q flag ever, what's the point of forever carrying the "rm foo*" when we know it's foo.out, just because a future Makefile change might add foo.blah? Doesn't seem like something we'd trip over, and the .gitignore/rm rule is just misleading now...
