make with MULTICALL is missing symlink from test to [

[SuperSandro2000]

When trying to build i3 we encountered the following error from meson:

meson.build:128:60: ERROR: Program or command '[' not found or not executable

which made me realize that the symlink from test to [ is not created when calling the makefile with MULTICALL.

[jhscheer]

Does #2432 fix this issue?

[SuperSandro2000]

I don't think so. I am currently creating a symlink here 635cb0a (#116274) which results in an exectuable [ script with the content:

$ cat result/bin/\[
#!/nix/store/8kzsmwhvywdpd1zrygm0cb4zk7nqxga6-bash-4.4-p23/bin/sh
/nix/store/gas9wi3zc4a58di535vz14bjn1ch6m6p-uutils-coreutils-unstable-2021-06-17/bin/test "$@"
exit $?

This is required for me to execute the [ binary similar to gnu-coreutils or busybox/toybox.

[miDeb]

We'd have to create the symlink in the makefile. I wonder if we also need to have symlinks for all the hashsum algorithms, such as md5sum.

[SuperSandro2000]

It is not as easy as that because the multicall binary will not know how to handle [.

[miDeb]

If you create a symlink called [ pointing to the multicall binary (or to the test binary) it should work on master, I think?

[SuperSandro2000]

Yeah, that works. I only skimmed the diff and didn't notice it. Now the final piece is that the makefile generates the symlink by default.

[miDeb]

So I actually think that [ should be implemented as a separate utility, because GNU's test doesn't change its behavior based on the binary name (or the name of the symlink). I'll post a PR soon.
After some more investigation this doesn't seem to be easily possible, because [ is not a valid rust crate/feature name. This means that we'd have to add heavy workarounds in GNUmakefile, which would obviously not work when installed with cargo install. So, I'll post a patch to create a symlink in the meantime.

I'll watch rust-lang/cargo#1706, which should make this possible, because afaict we'd only need a workaround for the feature name restriction anymore.