CTest in C++ container not found

[ibis-hdl]

• VSCode Version: 1.66.2
• Local OS Version: Windows 10
• Local chip architecture: <x86, arm64, Apple Silicon> x86/64
• Reproduces in: Remote - Containers
• Name of Dev Container Definition with Issue: cpp

Steps to Reproduce:

1. Create a container as usual
2. run cmake
3. run ctest - it's not found

All went fine here until I want to run ctest from VS Code's terminal. cmake is a link to ´/opt/cmake/bin/cmake´, but there isn't one for ctest (also for cpack too)

$ which cmake
/usr/local/bin/cmake
$ ll /opt/cmake/bin/
total 82776
drwxr-xr-x 2 root root     4096 Apr 12 14:15 ./
drwxr-xr-x 6 root root     4096 Apr 29 16:41 ../
-rwxr-xr-x 1 root root 13456920 Apr 12 14:15 ccmake*
-rwxr-xr-x 1 root root 13501208 Apr 12 14:15 cmake*
-rwxr-xr-x 1 root root 28918368 Apr 12 14:15 cmake-gui*
-rwxr-xr-x 1 root root 13955320 Apr 12 14:15 cpack*
-rwxr-xr-x 1 root root 14908088 Apr 12 14:15 ctest*
$ echo $PATH
/vscode/vscode-server/bin/linux-x64/dfd34e8260c270da74b5c2d86d61aee4b6d56977/bin/remote-cli:/usr/local/python/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/vcpkg:/usr/local/py-utils/bin:/home/vscode/.local/bin
$ ll /home/vscode/.local/bin/
total 184
drwxr-xr-x 3 vscode vscode   4096 Apr 30 17:27 ./
drwx------ 1 vscode vscode   4096 Apr 30 17:27 ../
-rwxr-xr-x 1 vscode vscode 150562 Apr 30 17:27 bottle.py*
-rwxr-xr-x 1 vscode vscode    209 Apr 30 17:27 conan*
-rwxr-xr-x 1 vscode vscode    222 Apr 30 17:27 conan_build_info*
-rwxr-xr-x 1 vscode vscode    216 Apr 30 17:27 conan_server*
-rwxr-xr-x 1 vscode vscode    244 Apr 30 17:27 normalizer*
drwxr-xr-x 2 vscode vscode   4096 Apr 30 17:27 __pycache__/
-rwxr-xr-x 1 vscode vscode    207 Apr 30 17:27 tqdm*
$ ll /usr/local/bin/c*
lrwxrwxrwx 1 root root  20 Apr 29 16:41 /usr/local/bin/cmake -> /opt/cmake/bin/cmake*
-rwxr-xr-x 1 root root 331 Oct 29  2021 /usr/local/bin/code*

So the other cmake utils aren't in path or are sym linked into.

I could tweak Dockerfile/devcontainer.json but, I think this should come from vscode-dev-containers setup.

Probably on bottom, the other links are missing cpp/.devcontainer/reinstall-cmake.sh

[bamurtaugh]

Thanks for opening @ibis-hdl.

Are the commands I ran in-line with yours?

• cmake .
• ctest in the build folder, it resulted in No tests were found!!!

Want to check this is what you encountered or if I should test in a different way.

[ibis-hdl]

Thanks for answer :)

I'm using Remote-Containers 0.231.6 in VS Code 1.66.2

I did in the devcontainer:

$ cmake --preset linux-clang-release
$ cmake --build --preset linux-clang-release
$ pushd build/linux-clang-release/
$ ctest
bash: ctest: command not found
$ /opt/cmake/bin/ctest 
Test project /workspaces/compiler/build/linux-clang-release
...

Obviously ctest isn't in the path as it should be, other CMake tools too.

Dockerfile is

ARG VARIANT="bullseye"
FROM mcr.microsoft.com/vscode/devcontainers/cpp:0-${VARIANT}
ARG REINSTALL_CMAKE_VERSION_FROM_SOURCE="3.23.1"
COPY ./reinstall-cmake.sh /tmp/
RUN if [ "${REINSTALL_CMAKE_VERSION_FROM_SOURCE}" != "none" ]; then \
        chmod +x /tmp/reinstall-cmake.sh && /tmp/reinstall-cmake.sh ${REINSTALL_CMAKE_VERSION_FROM_SOURCE}; \
    fi \
    && rm -f /tmp/reinstall-cmake.sh

[bamurtaugh]

Got it, thanks for the info! So the issue is that ctest results in bash: ctest: command not found.

When I added and reopened in this dev container, I was prompted to configure with the CMake Tools extension:

You can also execute this with command Cmake: Configure. Configuring with the extension enabled me to then use things like ctest. Did you configure with this extension?

[ibis-hdl]

No idea, CMake: Configure isn't avaiable inside the container. I'm using in devcontainer.json

	"extensions": [
		"ms-vscode.cpptools",
		"ms-vscode.cmake-tools",
                ...

These issue raises by use of terminal.

[bamurtaugh]

No idea, CMake: Configure isn't avaiable inside the container

This is interesting - if you look in the Extensions view, is the CMake Tools extension installed?

If you start typing CMake in the command palette (F1), could you share a screenshot of what you see?

[ibis-hdl]

Today, I can't reproduce the issue with missing cmake tools inside container. Anyway, with:

I can configure and build, call CTest from VS Code Menus, but it failed to run with preset:

In VS Code terminal, I can start it manually as:

but not as:

My CMakePresets is (hopefully not to much reduced to the releavant parts):

{
    "version": 3,
    "cmakeMinimumRequired": {
        "major": 3,
        "minor": 20,
        "patch": 0
    },
    "configurePresets": [
        {
            "name": "use-ninja",
            "description": "Default build tool",
            "hidden": true,
            "generator": "Ninja",
            "cacheVariables": {
                "CMAKE_EXPORT_COMPILE_COMMANDS": "ON"
            }
        },
        {
            "name": "default-dirs",
            "description": "Default build and install directories",
            "hidden": true,
            "binaryDir": "${sourceDir}/build/${presetName}",
            "cacheVariables": {
                "CMAKE_INSTALL_PREFIX": "${sourceDir}/build/${presetName}/install"
            }
        },
        {
            "name": "release-build",
            "hidden": true,
            "cacheVariables": {
                "CMAKE_BUILD_TYPE": "Release"
            }
        },
        {
            "name": "compiler-clang",
            "description": "Clang C language family frontend for LLVM",
            "hidden": true,
            "inherits": [
                "default-dirs",
                "use-ninja"
            ],
            "cacheVariables": {
                "CMAKE_CXX_COMPILER": "clang++"
            }
        },
        {
            "name": "linux-default",
            "description": "Linux common settings",
            "hidden": true,
            "vendor": {
                "microsoft.com/VisualStudioSettings/CMake/1.0": {
                    "hostOS": [
                        "Linux"
                    ]
                },
                "microsoft.com/VisualStudioRemoteSettings/CMake/1.0": {
                }
              }
        },
        {
            "name": "linux-clang-release",
            "displayName": "Linux Clang: Release",
            "description": "Linux/WSL2 LLVM Clang compiler: Release",
            "inherits": [
                "linux-default",
                "compiler-clang",
                "release-build"
            ]
        },
        {
            "name": "ci-default",
            "hidden": true
        },
        {
            "name": "ci-linux",
            "description": "used by the ci pipeline",
            "inherits": [
                "linux-clang-release",
                "ci-default"
            ]
        }

    ],
    "buildPresets": [
        {
            "name": "ci-linux",
            "configurePreset": "ci-linux"
        }
    ],
    "testPresets": [
        {
            "name": "test-default",
            "hidden": true,
            "output": {
                "outputOnFailure": true
            },
            "execution": {
                "noTestsAction": "error",
                "stopOnFailure": false
            }
        },
        {
            "name": "ci-linux",
            "configurePreset": "ci-linux",
            "inherits": [
                "test-default"
            ]
        }
    ]
}

[bamurtaugh]

cc @bobbrow any thoughts on the above I can configure and build, call CTest from VS Code Menus, but it failed to run with preset?

[bobbrow]

@bamurtaugh the problem appears to be that there is no symlink from ctest -> /opt/cmake/bin/ctest which I think was already stated. To deal with path issues like this, CMake Tools has a setting cmake.ctestPath that should allow you to work around the problem until the container is updated with the symlink. Can you try setting it to:

  "cmake.ctestPath": "/opt/cmake/bin/ctest"

[ibis-hdl]

YES, simply append

ln -s /opt/cmake/bin/ctest /usr/local/bin/ctest

at containers/cpp/.devcontainer/reinstall-cmake.sh

[ibis-hdl]

any progress?

[bamurtaugh]

Thanks for the ping!

Our team has been actively focused on an updated plan for community contributions and this repo moving forward, which we've now outlined in this issue: #1589. This includes moving to a couple new repos for images and Features (https://github.com/devcontainers/images, https://github.com/devcontainers/features), and we anticipate to have a similar repo and process for templates/definitions.

Please let me know if you have any questions, thank you!

[bobbrow]

@ibis-hdl I see this PR to add the symlink: #1598

@bamurtaugh any chance you can merge it in?

cc: @michaelbprice

[michaelbprice]

@ibis-hdl I see this PR to add the symlink: #1598

@bamurtaugh any chance you can merge it in?

cc: @michaelbprice

@bobbrow @bamurtaugh - Should I go ahead and add symlinks for the other CMake utilities beyond ctest? I was hesitant at first because it wasn't needed to solve my immediate problem, but if other people have noticed cpack symlink missing too, it probably justifies me adding that to the PR.

[bamurtaugh]

As highlighted in #1589, we will ultimately be archiving this repository and focusing new work on the repos in the devcontainers org, so we'll be focusing on security patches in this repo, rather than new additions or templates, moving forward.

Does the change make sense as part of the new C++ image? We will also soon have a new repo for a subset of dev container definitions (a.k.a. templates) in the containers folder of this repository, so it may make sense to open a PR on the new C++ template when that repo is available.

[michaelbprice]

As highlighted in #1589, we will ultimately be archiving this repository and focusing new work on the repos in the devcontainers org, so we'll be focusing on security patches in this repo, rather than new additions or templates, moving forward.

Do we have an idea when the transition to using the new images will be complete?

Does the change make sense as part of the new C++ image? We will also soon have a new repo for a subset of dev container definitions (a.k.a. templates) in the containers folder of this repository, so it may make sense to open a PR on the new C++ template when that repo is available.

There is some value in having a distinct CMake devcontainer template in addition to a generic C++ one. The same might be also true for a Make container, but @bobbrow would have a better understanding of the tradeoffs, I think.