USE_CCACHE logic with $(shell which) does not work properly

[akien-mga]

The current Makefile tries to check for the availability of ccache with:

CCACHE?=ccache
USE_CCACHE?=$(shell which $(CCACHE) 2>&1 > /dev/null && echo yes)

I'm not a Makefile expert, but this seems to have several issues:

• It seems that CCACHE?=ccache is expanded too late, so when USE_CCACHE?= is called the $(CCACHE) variable is empty in my case, triggering the which usage log as shown in Makefile: Fix display of configure report on Bash #193.
• Even when fixing it by hardcoding CCACHE:=ccache or passing make CCACHE=ccache, the redirection to /dev/null does not seem to work as expected. See e.g. with a purposedly typoed CCACHE definition:

$ make CCACHE=ccachetypo
 OPTIMIZE            : yes
 USE_CCACHE          : which: no ccachetypo in (/bin:/usr/bin:/usr/local/bin:/usr/local/games:/usr/games:/usr/lib64/qt4/bin:/usr/lib64/qt5/bin:/home/akien/.cargo/bin:/home/akien/.local/bin:/home/akien/bin:/home/akien/.cargo/bin)
 CCACHE              : ccachetypo

[ghost]

Weird. You stated Bash 4.3.48 in #193. Is that Bash the distro-vanilla Bash?

How does each of your other shells behave? Is there any chance to try attributing a Make or Bash bug?

[Szunti]

From the bash manual:

   Note that the order of redirections is significant.  For example, the command

          ls > dirlist 2>&1

   directs both standard output and standard error to the file dirlist, while the command

          ls 2>&1 > dirlist

   directs only the standard output to file dirlist, because the standard error was duplicated from the   standard output  before  the  standard
   output was redirected to dirlist.

Looks like you have to switch the redirection order.

[ghost]

Oh, I understand now.

So there was no shell or make oddity, but a probably unintended swap when the redirection was firstly written, arising as a problem years later, after eventually being combined with an uncommonly verbose flavor of which.

Thanks!