Question: is usage via shell wrappers supported?

[alalazo]

We have been using kcov in Spack since a while to get the coverage of a couple of bash scripts that are part of the project. Since these scripts are called indirectly by a Python program, to get their coverage during unit tests execution we came up with the solution of using a wrapper for the shell interpreter, and basically substitute the shebang:

#!/bin/bash

with:

#!/path/to/wrapper

The current wrapper looks like this:

#!/bin/bash
#
# This script acts like bash but runs kcov on the input script. We use it
# to get coverage for Spack's bash scripts.
#

kcov "$SPACK_ROOT/coverage" "$@"

and $@ gets expanded to the call of the initial script. For instance calling:

$ /opt/spack/lib/spack/env/gcc/gcc -c -fPIC -O2 ztest44416.c

where /opt/spack/lib/spack/env/gcc/gcc is the shell script being tested results in the interpreter calling:

kcov /opt/spack/coverage /opt/spack/lib/spack/env/gcc/gcc -c -fPIC -O2 ztest44416.c

Now, the issue is that this works for us with kcov v34 but any later version of kcov fails, see spack/spack#23164.

I'm currently trying to pin down the issues with kcov v38 but it seems there are multiple (e.g. kcov behaves differently if a full path to the wrapper is passed vs. just the basename with script being executable and in the PATH) and I was wondering if this approach is supported at all since I can't find any documentation for it, if I hit a bug in kcov or something else.

Let me know if you need more details, Thank you.

[alalazo]

I was able to get around most of the issues we face simply inserting a -- before the script to be analysed. Hope it makes sense, since I didn't see it documented. On the example above it means the call to kcov is:

kcov /opt/spack/coverage -- /opt/spack/lib/spack/env/gcc/gcc -c -fPIC -O2 ztest44416.c

[SimonKagstrom]

Well, I think it should work, and I'm not really sure why it would be different in v34 or later versions. Looking at the git changes, one thing to try could be

--bash-dont-parse-binary-dir

but other than that I don't really know. Good that you found a workaround, but I'm not really sure why the -- changes things.