Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmake executable path is saved and works from shell but Bad CMake executable error remains #2467

Closed
pantonox opened this issue Mar 29, 2022 · 6 comments
Labels
Feature: configure upstream Bugs related to issues in an upstream project

Comments

@pantonox
Copy link

Brief Issue Summary

after adding settings.json with the content below to the project, the plugin does still not find cmake but the same path works from the shell.

{
"cmake.cmakePath": "/opt/apps/resif/iris/2020b/broadwell/software/CMake/3.18.4-GCCcore-10.2.0/bin/cmake"
}

The bug happens in a university cluster environment where I have no sudo permissions. Cmake is loaded as software module (easybuild) from within the terminal of a vscode remote session

CMake Tools Diagnostics

(base) 0 [ggg@ggg bin](2644620 N/T/CN)$ module load devel/CMake/3.18.4-GCCcore-10.2.0
(base) 0 [gggy@ggg bin](2644620 N/T/CN)$ `CMake: Log Diagnostics`
bash: CMake:: command not found
(base) 127 [ggg@ggg bin](2644620 N/T/CN)$ CMake: Log Diagnostics
bash: CMake:: command not found
(base) 127 [ggg@ggg bin](2644620 N/T/CN)$ which cmake
/opt/apps/resif/iris/2020b/broadwell/software/CMake/3.18.4-GCCcore-10.2.0/bin/cmake
(base) 0 [ggg@ggg bin](2644620 N/T/CN)$ 

Debug Log

<!-- Paste the debug log contents HERE -->
@bobbrow
Copy link
Member

bobbrow commented Mar 29, 2022

Can you try closing and reopening VS Code to see if that fixes it? That would confirm that updating the setting is not taking effect. Thank you!

@bobbrow bobbrow added more info needed More info is needed from the community for us to properly triage and investigate. Feature: settings labels Mar 29, 2022
@pantonox
Copy link
Author

  1. I updated settings.json as follows (added cmake logging):
    {
    "cmake.cmakePath": "/opt/apps/resif/iris/2020b/broadwell/software/CMake/3.18.4-GCCcore-10.2.0/bin/cmake",
    "cmake.loggingLevel": "debug"
    }
  2. Loaded the cmake module on the remote node via a tunnel (from ubuntu terminal outside vscode)
  3. Opened a local vscode instance and use the remote development plugin to connect to the compute node
  4. Opened the project folder
  5. Vscode printed output:
    [main] Safe constructing new CMakeTools instance
    [variant] Constructing VariantManager
    [main] Constructing new CMakeTools instance
    [main] Starting CMakeTools second-phase init
    [variant] Loaded new set of variants
    [main] CMakeTools instance initialization complete.
    [kit] Reading kits file /home/users/pantony/.local/share/CMakeTools/cmake-tools-kits.json
    [kit] Successfully loaded 1 kits from /home/users/pantony/.local/share/CMakeTools/cmake-tools-kits.json
    [kit] Not reading non-existent kits file: /home/users/pantony/vscodeRemote/cppRemote/.vscode/cmake-kits.json
    [main] Injecting new Kit into CMake driver
    [extension] Configuring workspace on open file:///home/users/pantony/vscodeRemote/cppRemote
    [main] Configuring folder: cppRemote
    [main] Saving open files before configure/build
    [cache] Reading CMake cache file
    [cache] Cache file does not exist: Returning empty cache data
  6. checking from vscode terminal if cmake is available (and seeing that it is not available):
    (hcs_20220301) 0 [ggg@ggg](2645404 N/T/CN)$ which cmake
    /usr/bin/which: no cmake in (/mnt/irisgpfs/users/pantony/.vscode-server/bin/c722ca6c7eed3d7987c0d5c3df5c45f6b15e77d1/bin/remote-cli:/home/users/pantony/miniconda3/envs/hcs_20220301/bin:/home/users/pantony/miniconda3/condabin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/usr/share/lmod/lmod/libexec:/home/users/pantony/.local/bin:/home/users/pantony/bin:/usr/share/lmod/lmod/libexec)
  7. checking from ubuntu terminal if cmake is available in tunnel (yes it is)
    (hcs_20220301) 0 [ggg@ggg ~](2645404 N/T/CN)$ which cmake
    /opt/apps/resif/iris/2020b/broadwell/software/CMake/3.18.4-GCCcore-10.2.0/bin/cmake
  8. Anyway trying to build project in vscode cmake tool
    Error1: Build failed: Unable to configure the project
    Error2: Bad CMake executable: "/opt/apps/resif/iris/2020b/broadwell/software/CMake/3.18.4-GCCcore-10.2.0/bin/cmake". Check to make sure it is installed or the value of the "cmake.cmakePath" setting contains the correct path
  9. Loading module again in vscode terminal (now vscode can find it at least in the terminal)
    (hcs_20220301) 0 [ggg@ggg cppRemote](2645404 N/T/CN)$ module load devel/CMake/3.18.4-GCCcore-10.2.0
    (hcs_20220301) 0 [ggg@ggg cppRemote](2645404 N/T/CN)$ which cmake
    /opt/apps/resif/iris/2020b/broadwell/software/CMake/3.18.4-GCCcore-10.2.0/bin/cmake
  10. Trying again to build with cmake plugin in vscode
    Error1: Build failed: Unable to configure the project
    Error2: Bad CMake executable: "/opt/apps/resif/iris/2020b/broadwell/software/CMake/3.18.4-GCCcore-10.2.0/bin/cmake". Check to make sure it is installed or the value of the "cmake.cmakePath" setting contains the correct path
  11. Sharing thoughts with you:
    -It seems that the cmake module loaded outside of vscode is not visible from vscode
    -Loading the module from the vscode terminal does not fix the problem and that let's me believe that vscode needs to find cmake at vscode instance launch
    -Are my thoughts correct?
    -How can we make the loaded cmake module visible to the remote vscode session at the moment of it's initialization?

@bobbrow
Copy link
Member

bobbrow commented Mar 30, 2022

Unfortunately, changing the environment in the VS Code Terminal so that it can find your version of CMake does not update the environment that the extension runs in. Does updating your .bash_rc or .profile to load the module allow the environment to be set up initially when VS Code connects remotely?

I'm not sure that there's anything we can do in our extension to fix this. This looks more like an issue for the Remote extension to try to help you with. I would recommend asking the question here: https://github.com/microsoft/vscode-remote-release/issues/new/choose

@bobbrow bobbrow added upstream Bugs related to issues in an upstream project Feature: configure and removed more info needed More info is needed from the community for us to properly triage and investigate. Feature: settings labels Mar 30, 2022
@pantonox
Copy link
Author

pantonox commented Mar 31, 2022

Good news: Loading the cmake module via .bashrc on the remote machine solves the problem and cmake is now found at startup of the remote vscode session. Thanks for the fast and helpful feedback.

Status and next steps:

  1. Building and running a simple hello world program now works fine via cmake-tools
  2. Triggering debugging from the cmake-tools plugin gives the following error:

The program '/home/users/ggg/vscodeRemote/cppRemote/build/main' has exited with code 42 (0x0000002a).

ERROR: Unable to start debugging. Unexpected GDB output from command "-interpreter-exec console "set env BASH_FUNC_module() () { eval $($LMOD_CMD bash "$@") && eval $(${LMOD_SETTARG_CMD:-:} -s sh)
}"". Problem parsing arguments: interpreter-exec console "set env BASH_FUNC_module() () { eval $($LMOD_CMD bash "$@") && eval $(${LMOD_SETTARG_CMD:-:} -s sh)

  1. Please let me know if you prefer that I edit the github issue title ("Setting up vscode-cmake-tools for remote debugging on a cluster") or if you prefer me to open another issue ("gdb cannot start debugging in cmake-tools remote session").
    PS: gdb version on remote machine: GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-120.el7

  2. Could it be that some more environment variables need to be set on the remote machine via .bashrc for enabling remote debugging via cmake-tools?

@bobbrow
Copy link
Member

bobbrow commented Mar 31, 2022

Good news: Loading the cmake module via .bashrc on the remote machine solves the problem and cmake is now found at startup of the remote vscode session. Thanks for the fast and helpful feedback.

👍

The second issue you mention is the same as this one: #2442. You may want to try removing that variable (BASH_FUNC_module) from the environment in your .bash_rc as a workaround until we address this issue. Anything with a ${...} in it causes the debugger to fail.

@pantonox
Copy link
Author

pantonox commented Apr 1, 2022

For the time where you are going to work on #2442, I will use the following workaround for debugging:

  1. build with cmake-tools
  2. use the following launch.json for Run>StartDebugging:
    {
    "version": "2.0.0",
    "configurations": [
    {
    "program": "${workspaceRoot}/build/main",
    "name": "Debug",
    "type": "cppdbg",
    "request": "launch",
    "cwd": "${workspaceRoot}",
    "preLaunchTask": ""
    }
    ]
    }
  3. see also:
    https://vector-of-bool.github.io/docs/vscode-cmake-tools/debugging.html#debugging-launch-json

@pantonox pantonox closed this as completed Apr 4, 2022
@github-actions github-actions bot locked and limited conversation to collaborators May 19, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Feature: configure upstream Bugs related to issues in an upstream project
Projects
None yet
Development

No branches or pull requests

2 participants