Different configTemplate depending on executed tests

[voltamund]

First of all thanks for this fantastic extension.

Checklist

• Checked Support page

Is your feature request related to a problem? Please describe.
I wanted to run / debug cross-compiled google tests on a remote target with this extension. I have checked some existing issues and discussions related to remote execution and could set it up. I use a shell script as an executionWrapper. The script checks for --help and --gtest_list_tests arguments to detect test discovery. In that case it calls qemu directly to list the tests. Otherwise, the script rsyncs the test executable to the target hardware and executes the tests over ssh. This works without issues.
For remote debugging I have added a configTemplate with some deploySteps. This also works nicely.
I also build some of the tests for the build machine architecture (native, not cross-compiled). I can use different advancedExecutables items for the tests that can be executed locally and for the tests that should run remotely. The only remaining issue is that I can only have one configTemplate in my settings.json. If the configTemplate has the settings for remote debugging it will not work for debugging tests that are executed locally (native). Perhaps there could be a configTemplate inside an advancedExecutables item or some other way (perhaps just with a pattern) to associate a configTemplate with an advancedExecutables item. This would use the correct launch config (local / remote debugging) depending on the executed tests.

[matepek]

Hey, Wow you are so good achieving all of this.
I will add this feature.
Also I would like to ask you to share some How To with us. All that stuff you achieved I would put to the SUPPORT.md file in this repo.

[voltamund]

Thanks for the update.

Here is an example of a testMate.cpp.debug.configTemplate that can be used for remote debugging of a test.
I have added some comments. This could be extended with setupCommands if more control over gdb is needed.

"testMate.cpp.debug.configTemplate": {
    "variables": {
        // Take active ssh target from ms-vscode.cpptools extension
        "device": "${command:C_Cpp.activeSshTarget}",
        "localBindAddress": "localhost",
        "gdbPort": "2345",
        //
        // targetDir is the directory on the remote device where rsync will put the test executable
        "targetDir": "/tmp/testing",
        //
        // targetFilePath is the full path of the test executable on the remote device,
        // ${filename} is the just the filename part from ${exec}
        "targetFilePath": "${targetDir}/${filename}"
    },
    "type": "${assert:testMate.cpp.debug.configTemplate doesn't support this platform!}",
    "linux": {
        "type": "cppdbg",
        "MIMode": "gdb",
    },
    "miDebuggerPath": "gdb-multiarch",
    "miDebuggerServerAddress": "${localBindAddress}:${gdbPort}",
    "deploySteps": [
        {
            // create directory for rsync
            "type": "ssh",
            "host": "${device}",
            "command": "mkdir -p ${targetDir}"
        },
        {
            // rsync test executable (${exec}) to remote device
            "type": "shell",
            "command": "rsync --archive --quiet \"${exec}\" ${device}:\"${targetFilePath}\""
        },
        {
            // run test executable under gdb server
            "type": "ssh",
            "host": {
                "hostName": "${device}",
                "localForwards": [
                    {
                        "bindAddress": "${localBindAddress}",
                        "port": "${gdbPort}",
                        "host": "localhost",
                        "hostPort": "${gdbPort}"
                    }
                ]
            },
            "command": "gdbserver --once :${gdbPort} ${targetFilePath} ${argsStr}",
            "continueOn": "Listening on port",
        }
    ]
}

[matepek]

Fixed in v4.9.0.

This issue was mentioned in CHANGELOG.md under a released entry so it is assumed to be fixed.
User verifications are always welcome.

[voltamund]

Thank you very much for this new feature. It works without issues for me.