Thread (2 messages) flat view 2 messages, 2 authors, 2021-07-22

Re: [PATCH v3 4/5] Makefile: the "cscope" target always creates a "cscope.out"

From: Ævar Arnfjörð Bjarmason <hidden>
Date: 2021-07-22 21:21:07

On Thu, Jul 22 2021, Junio C Hamano wrote:
Taylor Blau [off-list ref] writes:
quoted
quoted
quoted
 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?
quoted
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...
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help