make completion regression in 2.3 about bash-completion HOT 4 CLOSED

(If a comment is made on an ancient closed Github issue, does it make a sound? Anyway, for the record)

First, thanks for at least an explanation (unconvincing as it may be), because now it's clear which feature of my makefiles breaks completion, so I can work around this.

Second, here is a workaround (a hack, obviously, as it depends both on how GNU Make composes MAKEFLAGS and on how bash-completion invokes it), for anyone who like me would like to keep their prerequisiteless .SECONDARY:, thankyouverymuch:

ifeq ($(filter npq%,$(firstword $(MAKEFLAGS))),)
# not invoked for completion
.SECONDARY:
endif

Third, I'd love a clearer explanation of the problem with mixing prerequisiteless .SECONDARY: and interactive development, because I am not aware of any? Because it feels like one of those times when I'm missing something arcane but important!

from bash-completion.

Forwarding info from Tristan Wibberley, our make completion guru, and closing accordingly.

Ah

.SECONDARY: with no prequisites causes all targets to be intermediate.

I think it is a costly error to use prerequisiteless .SECONDARY in a makefile that is expected to be used interactively.

As such I don't think we need to support the PostgreSQL makefile tab completion. I think it would be misleading for users if we were to do so because users are likely to infer and assume that prerequisiteless .SECONDARY is something that can be safely present in a Makefile that is directly used in day-to-day interactive development work.

I think users will be protected from a variety of errors in routine processes and quality of software deliveries if that feature seems to be unsupported for interactive use - and that is the new situation.

This is why I've come to that conclusion

The brief summary [at https://www.gnu.org/software/make/manual/html_node/Special-Targets.html#Special-Targets] implies that the purpose of .SECONDARY: without any prerequisites is to prevent files from being deleted, however this comes with an important side-effect that means it is probably inappropriate for nearly all makefiles intended as commandline entrypoints and therefore does not need to be supported well.

[from https://www.gnu.org/software/make/manual/html_node/Chained-Rules.html#Chained-Rules]

"The first difference is what happens if the intermediate file does not exist. If an ordinary file b does not exist, and make considers a target that depends on b, it invariably creates b and then updates the target from b. But if b is an intermediate file, then make can leave well enough alone. It won’t bother updating b, or the ultimate target, unless some prerequisite of b is newer than that target or there is some other reason to update that target."

That is, if you remove an intermediate target and then invoke make again afterwards, it will NOT update the targets that depend on the intermediate target.

So prerequisiteless .SECONDARY is a dangerous feature to use for interactive development work and is only really safe in CI systems that ensure they eliminate any built files before invoking make and in subordinate makefiles that are used from scripts or a top-level makefile that can take precautions.

from bash-completion.

One clarification to the original description: fallback to generic file/dir completion doesn't actually happen (adding an arbitrarily named file doesn't result in it being listed), it just looks similar to it.

from bash-completion.

Stumbled across this after submitting #215, where there is a use case using phony targets on intermediate targets that you would like them to be included in the autocomplete.

from bash-completion.